summaryrefslogtreecommitdiffstats
path: root/cmake/QtBuildInternalsExtra.cmake.in
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Fix failing standalone tests on WindowsAlexandru Croitor2020-05-011-0/+8
| | | | | | | | | | | | | | | Due to the install prefix being changed for standalone tests, the correct $qt_prefix/bin folder was not added to the PATH environment variable when running tests. Make sure to always include the the original qt install prefix, even if a different install prefix is specified when configuring standalone tests. Amends 39090ea15c41eded8a233ec2633c0c657280297c Change-Id: I22aab732bb2bb679074a811d28d8209e1d535df3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add initial support for CMake "Ninja Multi-Config" generatorAlexandru Croitor2020-01-271-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add support for -nomake-tests and -nomake-examples equivalentsAlexandru Croitor2019-11-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A developer can pass either -DQT_NO_MAKE_TESTS=ON or -DQT_NO_MAKE_EXAMPLES=ON to exclude tests or examples from being built as part the default make target (when you write just make or ninja). With ninja, tests and examples can be built separately one by one, by typing $ ninja tst_foo or $ ninja example_bar Same can be done with the Makefile generator. $ make tst_foo All tests / examples can be built in one go by typing $ ninja tests/all or $ ninja examples/all With the Makefile generator unfortunately it's not as nice and is most likely an implementation detail, but it can still be done by running something like $ make -f CMakeFiles/Makefile2 tests/all or $ make -f CMakeFiles/Makefile2 examples/all Change-Id: I34f168b3ab41e952a21d3ace5634e25a9f41922e Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Propagate BUILD_TESTING and BUILD_EXAMPLESAlexandru Croitor2019-09-061-0/+4
| | | | | | | | | | | | | | As with qmake, you configure with or without -nomake tests -nomake examples, and the choice is propagated to other repositories. Do the same for CMake. It's still possible to opt out to build one or the other by passing -DBUILD_TESTING=OFF -DBUILD_EXAMPLES=OFF on the command line, which takes precedence over the value saved to QtBuildInternalsExtra. Change-Id: If0fbfa938d88309e7969c9bacc8d0bf86548bf5e Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
* Export architecture config test variablesLeander Beernaert2019-08-141-0/+3
| | | | | | | | | Export the architecture configuration variables from QtBase. There are other modules that require access to this information in order to enable certain features (e.g: qml_jit in QtDeclarative). Change-Id: If2c7f29ccb1c0b0a0db3d78ad133a2a6be12b5ad Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Ugly fix for handling QT_SOURCE_TREEAlexandru Croitor2019-07-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QT_SOURCE_TREE is a variable that is set in qtbase/.qmake.conf. In qtbase, it's used throughout various projects to find cpp sources when building standalone tests (among other things). Everything works fine with qmake, because even if qmake is invoked on the tests subfolder, qmake searches up the source directory tree until it finds a .qmake.conf file, and uses that. When building qttools with qmake, the qdoc project expects to have a QT_SOURCE_TREE value, but it's not actually set in the qttools/.qmake.conf file, so the generated include paths that use that value are incorrect. Curiously the build still succeeds. Now in CMake land we replaced QT_SOURCE_TREE with CMAKE_SOURCE_DIR, but that does not work properly when doing a standalone tests build, because the project in that case is the tests one, and not the qtbase one, so configuration fails in a developer build when trying to configure some private tests. So far I've found that only qtbase actively uses this value. A temporary fix is to save the qtbase source directory into a QT_SOURCE_TREE variable inside the generated BuildInternalsExtra.cmake file. The pro2cmake script is changed to handle presence of QT_SOURCE_TREE in a qrc file path. This is handled by finding the location of a .qmake.conf file starting from the project file absolute path. This is needed to stop the script from crashing when handling the mimedatabase test projects for example. The change also regenerates the relevant failing test projects, and thus standalone tests (when doing developer builds aka private_tests enabled) now configure and build successfully. Change-Id: I15adc6f4ab6e3056c43ed850196204e2229c4d98 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Fix non-prefix builds for non qtbase reposAlexandru Croitor2019-07-221-0/+4
| | | | | | | | | | | | | | | | QT_WILL_INSTALL was previously always set to ON when doing a qtdeclarative build, because CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT evaluated to false due to always having to set CMAKE_INSTALL_PREFIX to point to the qtbase build directory. Instead of recomputing the value of QT_WILL_INSTALL, compute it once while configuring qtbase, and add it to the generated QtBuildInternalsExtra.cmake file, so it propagates to all other repos that will be built. Change-Id: If8bf63e7501b5758fe7aa0f799cb0746704f4811 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* cmake: Generate QtBuildInternalsExtra at conftimeKevin Funk2019-06-051-0/+17
... using configure_file. Change-Id: Ibe3522c33e20a86c454b23919547775624f84755 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>