summaryrefslogtreecommitdiffstats
path: root/cmake/QtSetup.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Improve sanitizer detectionAlexandru Croitor2020-06-151-0/+1
| | | | | | | | | | | | | | | The change fixes the labels to show up correctly in the configure summary. It also allows enabling the sanitizer via the feature flags, e.g. -DFEATURE_sanitize_address=ON. Finally the qtbase sanitizer option is saved in QtBuildInternalsExtra so that repos built after qtbase have the same sanitizer options enabled. Change-Id: Ic9d9e3ce3c7ebbc244ced2e6d163d1ac8ee06b12 Fixes: QTBUG-84721 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Remove last traces of QT_BUILD_EXAMPLESKai Koehne2020-06-111-9/+1
| | | | | | | | Amends dc1dd51af3a35728235cb63a31b07ff76a652208 Task-number: QTBUG-84471 Change-Id: Ia525398aea4d90ac57c0f567ac8b48bf5ce80fa1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't add "d" suffix to MinGW debug librariesJoerg Bornemann2020-06-111-1/+9
| | | | | | | | | | To be in line with the qmake build we drop the "d" suffix for MinGW debug libraries unless the debug_and_release feature is enabled. Task-number: QTBUG-84781 Change-Id: I1b83492bff561d3d7647dde467931ec3866ae940 Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't configure examples by defaultAlexandru Croitor2020-06-101-1/+1
| | | | | | | | | Users / developers usually configure a single example. The CI can still continue to explicitly configure and build all examples. Task-number: QTBUG-84471 Change-Id: I1c9ac857e7ad0e5602037265194f0a6742386b51 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Make it possible to build tools when cross-compilingLeander Beernaert2020-06-021-1/+6
| | | | | | | | | | | | | | | | | | | This patch allows tools to be built for the target platform when the QT_BUILD_TOOLS_WHEN_CROSSCOMPILING parameter is set at configuration time. To avoid naming conflicts, the target tools are suffixed with "_native". The qt_get_tool_target_name() function can be used to get the tool name for both scenarios (cross and non-cross compilation). Extend pro2cmake to refer to the right target name for tools. The relevant write_XXX functions have a new target_ref parameter that will be "${target_name}" for tools and literally the target name for everything else. Fixes: QTBUG-81901 Change-Id: If4efbc1fae07a4a3a044dd09c9c06be6d517825e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make build system of installed Qt more relocatableAlexandru Croitor2020-05-071-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way. The following story inspired this change. If a user wants to build a Qt repo into a different install prefix than the usual Qt one, this will fail configuration because we look for various things like syncqt, qdoc, etc relative to CMAKE_INSTALL_PREFIX, which will now point to a different location where none of the above tools are located. The intent for such a use case is to support building Qt packages with Conan, which sets a random install prefix when configuring a repo. The idea is to derive the qt prefix dynamically from the QtBuildInternals package location. Essentially it's a reverse relative path from the QtBuildInternalsConfig.cmake file to the install prefix that was specified when initially configuring qtbase. Once the dynamic prefix is computed (so we know where the possibly relocated Qt is), we can find tools like syncqt and qdoc. This is an initial attempt to support a use case like that. More design work will probably needed in case if tools / libs need to be found in a location different than the Qt install prefix (so support for multiple install prefixes / search paths). An example of such a case would be when building qtdeclarative and qtquickcontrols2 as Conan packages in one go. Most likely the qmltyperegistrar tool will be located in the random install prefix set by Conan, so building qtquickcontrols2 might fail due to not finding the tool in the original Qt install prefix. As to the implementation details, the change does the following: - Dynamically computes and sets the QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when find_package()'ing QtBuildInternals. It's an absolute path pointing to where the relocated Qt is. - When building qtbase this variable is not yet available (due to QtBuildInternalsExtra not existing), in that case we set the variable to the absolute path of CMAKE_INSTALL_PREFIX (but only for the initial qtbase configuration). - Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used for standalone tests purposes. It's not needed now that we compute the location of the Qt prefix dynamically. - The Unixy qt-cmake and qt-cmake-private shell scripts now use a relative path to find the toolchain file we created. - The toolchain file also dynamically computes the location of the Qt packages, and adds them to CMAKE_PREFIX_PATH. - A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding tool locations, mkspecs dir, path environment setup for tools, etc. - Some places still use CMAKE_PREFIX_PATH in the following cases - When determining paths while configuring qtbase (valid cases) - When I wasn't sure what the behavior should be, so I left them as-is (an example is documentation generation, do we want to install it into the random Conan prefix, or into the main prefix? Currently it installs in the random prefix). Note that relocating a Qt installation does not work for non-prefix / non-installed builds, due to hardcoded paths to include directories and libraries in generated FooTargets.cmake files. Task-number: QTBUG-83999 Change-Id: I87d6558729db93121b1715771034b03ce3295923 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Handle super build non-prefix install prefix correctlyAlexandru Croitor2020-04-171-2/+2
| | | | | | | | | | | | | | | | | The install prefix in such a case is the qtbase build dir, and not the qt6 top-level build dir. This caused issues with certain incorrect paths being generated, including a broken qt-cmake-standalone-test script, as well as upon reconfiguration determining that a non-prefix build should be installed. The fix for a non-prefix build is to check explicitly for the qtbase build dir. This works both for super and non-super builds. Task-number: QTBUG-83496 Change-Id: Ida2393176c4c81da767023ff48159afdedfb0a19 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* CMake: Allow excluding tools and apps from the default 'all' targetAlexandru Croitor2020-04-021-0/+6
| | | | | | | | | | | | | | | | | | | | | | | Qt uses the qtNomakeTools() function to mark a directory which will not be built as part of the default target. This is especially important when cross-compiling (to iOS for example) because the build process might fail. The condition for not building these "GUI tool sub-directory projects" is the absence of the "tools" value in qmake's QT_BUILD_PARTS variable. Introduce a QT_NO_MAKE_TOOLS CMake variable. If the value is true, it's equivalent to "tools" not being present in QT_BUILD_PARTS. Introduce qt_exclude_tool_directories_from_default_target(). It's the qmake counter part to qtNomakeTools(). Teach pro2cmake to generate it where appropriate. Change-Id: If2e5958d91847ab139af0e452608510286e73fa0 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Remove APPLE prefix from platform namesTor Arne Vestbø2020-03-161-2/+2
| | | | | | | None of the other platforms have it. Change-Id: Ib448c2c03ba03f711b507ef391977c0e6aa7c192 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't build tests and examples by default on Android and iOSAlexandru Croitor2020-03-121-2/+2
| | | | | | Change-Id: Ia31733e2cadfb52d11426c40f3543bedc48342c4 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Port most of the configure summary supportAlexandru Croitor2020-03-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Teaches configurejson2cmake about summaries / reports, so things like enabled features, configure sections, notes, etc. Add relevant CMake API for adding summary sections and entries, as well as configure reports. The commands record the passed data, and the data is later evaluated when the summary needs to be printed. This is needed, to ensure that all features are evaluated by the time the summary is printed. Some report and summary entries are not generated if they mention a feature that is explicitly exclduded by configurejson2cmake's feature mapping dictionary. This is to prevent CMake from failing at configure time when trying to evaluate an unknown feature. We should re-enable these in the future. A few custom report types are skipped by configurejson2cmake (like values of qmake CONFIG or buildParts). These will have to be addressed a case-by-case basis if still needed. Change-Id: I95d74ce34734d347681905f15a781f64b5bd5edc Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix Ninja Multi-Config framework buildsAlexandru Croitor2020-03-061-0/+1
| | | | | | | | | | | | | | | | | | Depends on a new bleeding edge feature in as-of-yet unreleased CMake 3.18, that allows building macOS frameworks using the Ninja Multi-Config generator targeting more than one configuration. It uses the new CMAKE_FRAMEWORK_MULTI_CONFIG_POSTFIX_DEBUG property which tells CMake to create properly named debug artifacts in the Multi-Config ninja file. Without it, both debug and release artifacts would have the same location (no _debug) postfix, so it would be unclear which file ends up being compiled as last (the debug or release variant). Change-Id: I3e10832551731a18317da8f9667d96cec3dc3028 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* CMake: Port the 'debug_and_release' featureJoerg Bornemann2020-03-051-0/+3
| | | | | | | | This feature is read-only. It's controlled by the multi-config feature of CMake. It mainly exists for the qmake support. Change-Id: I322459598fe92568eda4d42319ded444537e95d4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add initial support for CMake "Ninja Multi-Config" generatorAlexandru Croitor2020-01-271-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 initial support for cross-building to iOSAlexandru Croitor2019-12-031-1/+14
| | | | | | | | | | | | | | | | | | | | | | 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>
* Rename / prefix all our private API functions with qt_Alexandru Croitor2019-11-141-1/+1
| | | | | | | | | | | Rename internal APIs like extend_target to qt_extend_target. Prefix apis with qt_ where required. Keep old names for compatibility until all their usages are removed. Change-Id: I9a13515a01857257a4c5be3a89253749d46a4f41 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Always build tests by default when building standalone testsAlexandru Croitor2019-11-131-0/+4
| | | | | | | | Amends 021c17c62f963a682c6a4b19f0c3d362c28a97ee Change-Id: I8181270ef7506eb5da4d3b43e105e100ed5581e4 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add support for -nomake-tests and -nomake-examples equivalentsAlexandru Croitor2019-11-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Make standalone tests build via top level repo projectAlexandru Croitor2019-11-081-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add support for benchmark conversionLeander Beernaert2019-11-041-0/+11
| | | | | | | | | | | | | Convert benchmark executables to add_qt_benchmark(). Currently add_qt_benchmark just calls add_qt_executable() and ensures that it they build under CMAKE_CURRENT_BUILD_DIR and do not install. Add QT_BUILD_BENCHMARKS option to enable/disable building of benchmarks. Change-Id: Id0bc676698d21d50048d97d9abef51d92ccb6638 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Pick the latest available C/C++ standard when compiling QtSimon Hausmann2019-10-171-5/+2
| | | | | | | | | | This maps the behavior of mkspecs/features/qt_common.prf and enables the use of C++17 for example in Android, where the toolchain supports it anyway. Change-Id: I41f4bdb160a3929e2fb78f36efb1ad5f2ad391a5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* Include QtPlatformSupport as part of find_package(Qt6BuildInternals)Alexandru Croitor2019-09-271-3/+0
| | | | | | | | | | | This is needed because the ported over requires() clauses from qmake to CMake are executed before qt_repo_build(), which means that all the custom platform variables that we set (like LINUX, APPLE_OSX) need to be available immediately after finding BuildInternals. Change-Id: I7345b69edf72c266508846766e64f42c99862d1d Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Propagate BUILD_TESTING and BUILD_EXAMPLESAlexandru Croitor2019-09-061-0/+3
| | | | | | | | | | | | | | 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
* Ugly fix for handling QT_SOURCE_TREEAlexandru Croitor2019-07-291-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-9/+17
| | | | | | | | | | | | | | | | 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>
* Allow prefix builds with developer-build as feature enabledSimon Hausmann2019-06-251-9/+14
| | | | | | | Just like with qmake, separate the two "features". Change-Id: Idf2a796c7c4aaa740c471688b2221d7041fed643 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Merge remote-tracking branch 'origin/wip/qt6' into wip/cmakeAlexandru Croitor2019-06-141-1/+1
| | | | | | | | | | This changes many different CMake places to mention Qt6 instead of Qt5. Note that some old qt5 cmake config files in corelib are probably not needed anymore, but I still renamed and kept them for now. Change-Id: Ie69e81540386a5af153f76c0242e18d48211bec4
* Android: Generate deployment-settings.jsonLeander Beernaert2019-06-121-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generate the android deployment settings json for android apk targets. QtPlatformAndroid is now also deployed as a public build dependency of QtCore. Some minor refactoring has been performed to the naming of variables and functions to better match the public facing apis. Extra settings for the file can be configured using the following target properties: set_target_properties(Core PROPERTIES QT_ANDROID_DEPLOYMENT_DEPENDENCIES "foo;bar" QT_ANDROID_EXTRA_LIBS "foo;bar" QT_ANDROID_EXTRA_PLUGINS "foo;bar" QT_ANDROID_PACKAGE_SOURCE_DIR "/foo/bar/" ) The file is generated using the function qt_android_generate_depoyment_settings(). We need to install the android template files and jar files during the android build as the androiddeployqt tool wont work if parts of it are split between the host install and the android install. Added QT_BUILD_QT variable to check whether we are building Qt from source. Finally, we also force the stdlib to shared via cmake configuration with -DANDROID_STL="c++_shared" Change-Id: I063c47e11749d56ba4c6f02101dbcc09e1b9fe87 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Android: Move Platform IncludeLeander Beernaert2019-06-061-0/+5
| | | | | | | | | Move the include of the platform from QtPlatformSupport to QtSetup. This no longer causes compile tests to fail since they expect explicit include paths instead of using CMAKE_MODULE_PATH. Change-Id: I9d3bed7845104d84422afb5a976ec14b111d259d Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* CMake: Disable autotests for non-developer buildsKai Koehne2019-06-051-1/+4
| | | | | | | | | | | Mimic the behavior in the qmake build system, and by default build tests for developer-build, and not build it for a normal build. To do this, we define BUILD_TESTING with the right default before including CTest, which does otherwise define the option itself. Change-Id: Ifa1b1156477919abc1e916ccd9e1e0a74e969ee6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Enable export of compile commands databaseSimon Hausmann2019-05-271-0/+5
| | | | | | | | | | For developer builds, enable the compile commands database by default. This allows Qt developers to use tools that utilize these (such as clang-tidy, etc.) without any extra setup. Change-Id: I79d70ef7dbe7c59864e93593c75f9ff6cd67c2ce Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CMake Build Bot
* Save and set the CMAKE_INSTALL_PREFIX in BuildInternal's Config fileAlexandru Croitor2019-05-151-2/+2
| | | | | | | | | | | | | | Once qtbase is built and installed, save the CMAKE_INSTALL_PREFIX that was used during the build, and set it when a consumer calls find_package(Qt5BuildInternals). This fixes a bug where syncqt can not be found when building qtsvg, while the developer specifies CMAKE_PREFIX_PATH to find the Qt packages, but does not set the CMAKE_INSTALL_PREFIX. Task-number: QTBUG-75544 Change-Id: I03fd23ba418af5115105610f3f9ed92664562945 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Implement developer / non-prefix buildsAlexandru Croitor2019-05-151-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A non-prefix build is a build where you don't have to run make install. To do a non-prefix build, pass -DFEATURE_developer_build=ON when invoking CMake on qtbase. Note that this of course also enables developer build features (private tests, etc). When doing a non-prefix build, the CMAKE_INSTALL_PREFIX cache variable will point to the qtbase build directory. Tests can be run without installing Qt (QPA plugins are picked up from the build dir). This patch stops installation of any files by forcing the make "install" target be a no-op. When invoking cmake on the qtsvg module (or any other module), the CMAKE_INSTALL_PREFIX variable should be set to the qtbase build directory. The developer-build feature is propagated via the QtCore Config file, so that when building other modules, you don't have to specify it on the command line again. As a result of the change, all libraries, plugins, tools, include dirs, CMake Config files, CMake Targets files, Macro files, etc, will be placed in the qtbase build directory, mimicking the file layout of an installed Qt file layout. Only examples and tests are kept in the separate module build directories, which is equivalent to how qmake does it. The following global variables contain paths for the appropriate prefix or non prefix builds: QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR, QT_CONFIG_INSTALL_DIR. These should be used by developers when deciding where files should be placed. All usages of install() are replaced by qt_install(), which has some additional logic on how to handle associationg of CMake targets to export names. When installing files, some consideration should be taken if qt_copy_or_install() needs to be used instead of qt_install(), which takes care of copying files from the source dir to the build dir when doing non-prefix builds. Tested with qtbase and qtsvg, developer builds, non-developer builds and static developer builds on Windows, Linux and macOS. Task-number: QTBUG-75581 Change-Id: I0ed27fb6467662dd24fb23aee6b95dd2c9c4061f Reviewed-by: Kevin Funk <kevin.funk@kdab.com> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
* Export tool config and target files for each relevant moduleAlexandru Croitor2019-05-021-11/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CMake will now generate config and target files for each module that provides tools. As a result, namespaced global targets such as Qt5::moc or Qt5::rcc can be made available. Third party projects that require just these tools, and not the Qt modules themselves, should specify CMAKE_PREFIX_PATH pointing to the installed Qt location, and call find_package(Qt5CoreTools), find_package(Qt5GuiTools), etc. It is also possible to call find_package(Qt5Tools REQUIRED Core Widgets) where the last option is a list of modules whose tools should be imported. Note that all the tools are in the Qt5:: namespace and not in the Qt5CoreTools:: or Qt5WidgetsTools:: namespace. This commit also changes the behavior regarding when to build tools while building Qt itself. When cross compiling Qt (checked via CMAKE_CROSSCOMPILING) or when -DQT_FORCE_FIND_TOOLS=TRUE is passed, tools added by add_qt_tool will always be searched for and not built. In this case the user has to specify the CMake variable QT_HOST_PATH pointing to an installed host Qt location. When not cross compiling, tools added by add_qt_tool are built from source. When building leaf modules (like qtsvg) that require some tool that was built in qtbase (like moc), the module project should contain a find_package(Qt5ToolsCore) call and specify an appropriate CMAKE_PREFIX_PATH so that the tool package is found. Note that because HOST_QT_TOOLS_DIRECTORY was replaced by QT_HOST_PATH, the ensure syncqt code was changed to make it work properly with both qtbase and qtsvg. Here's a list of tools and their module associations: qmake, moc, rcc, tracegen, qfloat16-tables, qlalr -> CoreTools qvkgen -> GuiTools uic -> WidgetTools dbus related tools -> DBusTools Task-number: QTBUG-74134 Change-Id: Ie67d1e2f8de46102b48eca008f0b50caf4fbe3ed Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
* Add a debug suffix to libraries and plugins on macOS and WindowsAlexandru Croitor2019-04-021-0/+8
| | | | | | | | | This is especially important on macOS when doing a debug build, because QPluginLoader is looking for the cocoa QPA plugin suffixed with "_debug" when executing a test or example. Change-Id: Ief23b3a82c567c16ab9dd30d04d1729031262d7d Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
* cmake: Start adding compiler flagsAlbert Astals Cid2019-02-211-0/+3
| | | | | | | | | Only has warnings for now Next to come is the support for developer-build and enabling Werror Change-Id: I8070dc06eb439c2a03007cce975c8147ff7e1582 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
* cmake: set a CMAKE_BUILD_TYPE if none was specifiedAlbert Astals Cid2019-02-211-0/+12
| | | | | | | Because the default "empty" CMAKE_BUILD_TYPE is a weird default Change-Id: I5768f67aa85dce4108e421d2f4eacdfb1cb5beb0 Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
* Add support for building conveniently with ccacheSimon Hausmann2019-02-191-0/+8
| | | | | | | | | Pass -DQT_USE_CCACHE=ON to enable the use of ccache. This avoids having to set up symlinks, which is useful when cross-compiling against different targets. Change-Id: I023fff105baaa538730997948aa122d2678887ce Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
* Fix finding syncqt when "cross compiling"Simon Hausmann2019-02-121-0/+2
| | | | | | | | This is not quite the correct design yet, but makes the existing mechanism work first. Change-Id: Idbc6f1380adc955a772eb6e5beb6b3a5f7f686bb Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
* Begin port of qtbase to CMakeSimon Hausmann2018-11-011-0/+47
Done-by: Alexandru Croitor <alexandru.croitor@qt.io> Done-by: Frederik Gladhorn <frederik.gladhorn@qt.io> Done-by: Kevin Funk <kevin.funk@kdab.com> Done-by: Mikhail Svetkin <mikhail.svetkin@qt.io> Done-by: Simon Hausmann <simon.hausmann@qt.io> Done-by: Tobias Hunger <tobias.hunger@qt.io> Done-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Done-by: Volker Krause <volker.krause@kdab.com> Change-Id: Ida4f8bd190f9a4849a1af7b5b7981337a5df5310 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Tobias Hunger <tobias.hunger@qt.io> Reviewed-by: Mikhail Svetkin <mikhail.svetkin@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-02 09:22:53 +0000