Commit Graph

16 Commits

Author SHA1 Message Date
Alexandru Croitor
9862cb4532 CMake: Write QT_MAC_SDK_VERSION into qconfig.pri
Task-number: QTBUG-84781
Change-Id: I9f4e979a7404dd45286e0a85a6f3772e53a2fd0b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-06-17 15:13:44 +02:00
Alexandru Croitor
2073a16497 CMake: Clean up AND NOT QT_BUILD_STANDALONE_TESTS in QtAutoDetect
Now that the whole file is not included when doing standalone tests,
the conditions are not needed anymore.

Change-Id: I49ddd2fc4a8327e09529948785f40cda5dedbb11
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-06-04 23:21:32 +02:00
Alexandru Croitor
dc26b30acd CMake: Protect against Qt toolchain file recursive inclusion
Three different people have encountered the issue that calling
calling qt-cmake on a project prints 1000 inclusion lines of the same
qt toolchain file, and then CMake bails out saying can't find the
CMAKE_MAKE_PROGRAM Ninja.

This happened because people accidentally called qt-cmake to configure
qtbase (instead of just cmake), which created a toolchain file that
chainloads itself recursively.

Error out when configuring qtbase, and when using the generated
toolchain file in the case when it would try to include itself.

The solution is to remove the qtbase CMakeCache.txt file, and
configure qtbase again, so it generates a proper qt.toolchain.cmake
file.

If somebody feels enthusiastic, they can move the check into the
qt-cmake and qt-cmake-private shell scripts, and error out before the
qtbase/CMakeCache.txt is polluted with the wrong toolchain file.
That is left for people that feel more comfortable with bash and batch
scripting.

Change-Id: If518c94791fe7c30731e6e462e347f26a5213c64
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-06-04 23:21:27 +02:00
Alexandru Croitor
fae09465c7 CMake: Default to building all configurations with Ninja Multi-Config
Thus we will build both Release and Debug configurations in Coin
when cmake --build . is executed, mimicking qmake's make which
builds both configurations in debug_and_release.

Task-number: QTBUG-80900
Change-Id: If48aca249eb84e690d3f9d51a733b3a25df1f7ca
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-05-19 10:16:05 +02:00
Alexandru Croitor
67ee92f4d8 CMake: Handle automatic rpath embedding correctly
Instead of using CMAKE_INSTALL_RPATH to embed an absolute path
to prefix/libdir into all targets, use the more sophisticated aproach
that qmake does.

For certain targets (modules, plugins, tools) use relative rpaths.
Otherwise embed absolute paths (examples, regular binaries).
Installed tests currently have no rpaths.

On certain platforms rpaths are not used (Windows, Android,
iOS / uikit).

Frameworks, app bundles and shallow bundles should also be handled
correctly.

Additional rpaths can be provided via QT_EXTRA_RPATHS variable
(similar to the -R option that configure takes).

Automatic embedding can be disabled either via QT_FEATURE_rpath=OFF
or QT_DISABLE_RPATH=ON.

Note that installed examples are not relocatable at the moment (due
to always having an absolute path rpath), so this is a missing feature
compared to qmake. This is due to missing information on where
examples will be installed, so a relative rpath can not be computed.

By default a Qt installation is relocatable, so there is no need to
pass -DQT_EXTRA_RPATHS=. like Coin used to do with qmake e.g. -R .

Relative rpaths will have the appropriate 'relative base' prefixed
to them (e.g $ORIGIN on linux and @loader_path on darwin platforms).
There is currently no support for other platforms that might have a
different 'relative base' than the ones mentioned above.

Any extra rpaths are saved to BuildInternalsExtra which are re-used
when building other repositories.

configurejson2cmake modified to include correct conditions for the
rpath feature.

It's very likely that we will need a new qt_add_internal_app()
function for gui apps that are to be installed to prefix/bin.
For example for Assistant from qttools. Currently such apps
use qt_add_executable().
The distinction is necessary to make sure that relative rpaths are
embedded into apps, but not executables (which tests are part of).

Amends e835a6853b

Task-number: QTBUG-83497
Change-Id: I3510f63c0a59489741116cc8ec3ef6a0a7704f25
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-04-17 15:59:25 +02:00
Alexandru Croitor
430232e44d CMake: Adjust PCH support for multi-arch iOS builds
Starting with CMake 3.18, there is PCH support for darwin multi-arch
builds, like iOS simulator_and_device builds.

Also enable PCH for Objective-C++ files when the support is there.

To enable PCH for Objective-C++, we need to do enable the OBJCXX
language as well, but conditionally, because on non-darwin platforms
the language is probably not available.

Introduce the qt_enable_cmake_languages() macro which is called
automatically by qt_build_repo_begin().

Change-Id: I0e7f44be6577ac54ce940470036626409920e272
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-04-03 21:51:06 +02:00
Alexandru Croitor
0446bf5ba3 CMake: Fix auto-detection of precompiled header support
PCH files were only used while building qtbase. Make sure the value
is exported to the BuildInternalsConfig file, so the value is re-used
when building other repositories.

Also disable PCH when building simulator_and_device iOS builds, because
CMake doesn't currently generate separate PCH files per architecture.

Change-Id: I79955ebc557b800bc3c704deac519fe80012c229
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2020-03-25 10:46:46 +01:00
Tor Arne Vestbø
39ad96033c Fix spelling mistakes
Change-Id: I389727ce9b8d3ef2a54156b682ef5aeccb39ebd2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-03-11 17:51:15 +01:00
Alexandru Croitor
627351f561 CMake: Set minimum deployment target for darwin platforms
Same value as QMAKE_IOS_DEPLOYMENT_TARGET in
mkspecs/macx-ios-clang/qmake.conf, etc.

Change-Id: I1f6a07d73c2126d0286e8d26f7e61a690607c8ce
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2020-03-06 17:12:40 +01:00
Alexandru Croitor
aa5e43d491 CMake: Adapt to latest upstream Ninja Multi-Config changes
Most of the NMC-specific variables were renamed to be more general.

Change-Id: I8ee2874fecb9e57480ce51db9183c6cf3dd100af
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-03-04 17:16:24 +01:00
Alexandru Croitor
6d29264e3e CMake: Set minimum deployment target only for host macOS
A future change will come that sets it for iOS and friends.

Change-Id: I74b688ee62d24137e3cdf5475e1a9e858698ccf0
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2020-02-21 16:16:26 +01:00
Alexandru Croitor
e9672c747c Set a default value for CMAKE_OSX_DEPLOYMENT_TARGET
This replicates the behavior of QMAKE_MACOSX_DEPLOYMENT_TARGET in
qmake.

Change-Id: I273cd26994f2edfc52dc7b6278252c37b65b2356
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2020-02-18 21:22:35 +01:00
Alexandru Croitor
c9bea1ad62 Add initial support for CMake "Ninja Multi-Config" generator
This allows doing debug_and_release builds with Ninja on all
platforms.
The "Ninja Multi-Config generator" is available starting with CMake
3.17.

Desired configurations can be set via CMAKE_CONFIGURATION_TYPES.
Possible values: "Release, Debug, RelWithDebInfo, MinRelSize".
For example -DCMAKE_CONFIGURATION_TYPES="Release;Debug".

The first configuration is the 'default' configuration which is
built when calling ninja with no arguments.

To build all targets of a certain configuration use "ninja all:Release"
or "ninja all:Debug".

To build all targets in all configurations use "ninja all:all".

Note that the first configuration influences which configuration of
tools will be used when building the libraries for all configurations.
In simple terms, when configured with
-DCMAKE_CONFIGURATION_TYPES="Release;Debug" the release version of moc
is used by AUTOMOC.
When configured with -DCMAKE_CONFIGURATION_TYPES="Debug;Release"
the debug version of moc is used by AUTOMOC.

Framework builds and Ninja Multi-Config don't currently work together
due to multiple bugs in CMake, which ends up generating an invalid ninja
file with duplicate rules. There are also issues with placement of the
debug artifacts.

This will be handled in a follow up patch after CMake is fixed.

Task-number: QTBUG-76899
Change-Id: If224adc0b71b7d1d6606738101536146aa866cd7
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2020-01-27 11:47:57 +00:00
Alexandru Croitor
55a15a1c1b Add initial support for cross-building to iOS
Tested locally with the following configurations:
- iOS device builds (arm64)
- iOS simulator builds (x86_64)
- iOS simulator_and_device builds (fat arm64 and x86_64 archives)

All iOS builds currently require a custom vcpkg fork which contains
fixes for building the required 3rd party libraries.

qtsvg, qtdeclarative, qtgraphicaleffects and qtquickcontrols2
have also been tested to build successfully.

simulator_and_device builds are also supported, but require an umerged
patch in upstream CMake as well as further patches to vcpkg.

Task-number: QTBUG-75576
Change-Id: Icd29913fbbd52a60e07ea5253fd9c7af7f8ce44c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
2019-12-03 13:35:59 +00:00
Alexandru Croitor
de3a806def Make standalone tests build via top level repo project
Previously repo/tests/CMakeLists.txt was a standalone project on which
CMake could be called. This was useful for Coin to be able to build
and package only tests, but was a bit troublesome because that means
having to specify the usual boilerplate like minimum CMake version,
which packages to find in every tests.pro project.

Instead of having a separate standalone project, modify the top level
project and associated CMake code to allow passing a special
QT_BUILD_STANDALONE_TESTS variable, which causes the top level project
to build only tests, and find Qt in the previously installed qt
location.

This also means that when building a repo, we generate a
${repo_name}TestsConfig.cmake file which does find_package on all the
modules that have been built as part of that repo. So that when
standalone tests bare built for that repo, the modules are
automatically found.

qt_set_up_standalone_tests_build() is modified to be a no-op because
it is not needed anymore. Its usage should be removed from all the
other repos, and then removed from qtbase.

Non-adjusted tests/CMakeLists.txt projects in other repositories
should still be buildable with the current code, until they are updated
to the new format.

Adjust the Coin build instructions to build the standalone tests in a
separate directory.

Adjust pro2cmake to generate new structure for the tests/tests.pro
projects.

Adjust the qtbase tests project.

Fixes: QTBUG-79239
Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-11-08 15:42:32 +00:00
Leander Beernaert
ccc581c9fd Add auto detection routines for android
Add QtAutoDectect cmake which has routines to handle the vcpkg detection
as well as set up some android configuration parameters. The latter will
contribute towards keeping the cmake configuration commands shorter when
targeting android.

Change-Id: I721291c8dce39b5c298565a46867ddcab2df90e8
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
2019-06-27 13:45:58 +00:00