summaryrefslogtreecommitdiffstats
path: root/cmake/QtBuildInternals
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Implement configure -optimize-debugJoerg Bornemann2020-08-201-1/+3
| | | | | | Task-number: QTBUG-85373 Change-Id: I3aba1fcf96e36544dd75a5e6adc5f770a9a45726 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Adjust compiler flag optimizations to qmake mkspec onesAlexandru Croitor2020-08-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are inconsistencies in the default optimization flags added by CMake across configurations like Release and RelWithDebInfo. In particular Release uses -O3, whereas RelWithDebInfo uses -O2, as well as usage of /INCREMENTAL in release configs with MSVC, etc. To make sure that the Qt 6 binaries built with CMake are consistent across configs, as well as consistent with the flags we used when building Qt 5 with qmake, add a horrible search and replace mechanism to replaces the CMake flags with what our mkspecs indicate to use. Ideally this would be done by providing custom CMake toolchain files for each platform we support, and we might revisit that later if the need really arises. To implement the replacing, we first need the flags that should be added. Port the QMAKE_CFLAGS_OPTIMIZE variables to CMake, which is done in QtCompilerOptimization.cmake. Then a new function called qt_internal_set_up_config_optimizations_like_in_qmake will look for any kind of optimization flags set in the CMAKE_<LANG>_FLAGS_<CONFIG> style variables, remove them, and add the appropriate flags that qmake mkspecs provide. On some platforms (like Windows MSVC) the function also alters the linker CMAKE_${TYPE}_LINKER_FLAGS_<CONFIG> style variables. The mechanism allows opting out of this replacing by setting the QT_USE_DEFAULT_CMAKE_OPTIMIZATION_FLAGS value. It also allows opting into removal of flags for custom configs by providing QT_ADDITIONAL_OPTIMIZATION_FLAG_CONFIGS. It's only removal, because we wouldn't know what kind of config it is, and thus what flags to add. The currently modified configs are: Release, RelWithDebInfo, MinSizeRel, Debug aka the usual default CMake provided ones. The mechanism is only applied to C-like languages. ASM is not handled to be on the safe side due to not knowing what kind of compiler flags the platform assembler might take. It's also important to skip RC on MSVC platforms. Task-number: QTBUG-85992 Change-Id: I3712d5cd5a34fceab54f56a6fa46b4e678952362 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake Build: Disable pkg-config for QNXCristian Adam2020-08-191-1/+1
| | | | | | | | QNX doesn't come with pkg-config support. Task-number: QTBUG-83202 Change-Id: I2ac0c014a071b83ef9a2d8114bae0e9ff9b3b422 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix configuration of CMake tests in-build-treeAlexandru Croitor2020-07-201-5/+11
| | | | | | | | | | | | Qt6 package was not found the tests were configured in-tree as opposed to standalone tests. Use the same trick we do for building examples in-tree. Specify the path to the build tree packages, and don't create targets. Amends 96e3ee06598d00e7155f3f8574759ea658a134e5 Change-Id: Ia60de416ce0afff5bd40be8c0c6e3c7898fd7ebf Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix various issues with the Android buildAlexandru Croitor2020-07-091-2/+1
| | | | | | | | | | | | | | | | | | | Certain resources and compiled jar files have to be copied into the non-prefix build dir location. They were previously only installed, which doesn't do anything in a non-prefix build. Change pro2cmake to generate code that places the compiled java jars into QT_BUILD_DIR, so that non-prefix builds work. Place the module dependencies xml files into lib folder in non-prefix builds. Don't special case the output and install location of the Android QPA plugin. Task-number: QTBUG-85399 Change-Id: I4ac9d3929ea8ecc95ec99a77e621ad2121b68832 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't use libraries in /usr/local by default on macOSAlexandru Croitor2020-06-291-0/+92
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qmake builds of Qt don't use libraries in /usr/local because the path is not considered a system path. Only the SDK path should be used as a source of system libraries. We should do the same for the CMake builds, which involves a couple of things. Tell CMake not to consider /usr/local (and a bunch of other paths) as system prefix paths. Disable pkg-config usage which by default is not used in qmake Windows and macOS builds. If a user wishes to use libraries located in /usr/local on macOS, they can explicitly enable the behavior via -DFEATURE_pkg_config=ON. In addition to enabling pkg-config, that will also disable the system prefix modification described above. Implementation notes To disable pkg-config usage, we set an empty path for PKG_CONFIG_EXECUTABLE, because there is no other good way. The downside to this is that a lot of warning messages will be printed that the pkg-config package can not be found. The pkg-config feature needs to be computed in QtBuildInternals before qtbase/src/configure.cmake, because it's too late to do it in that file where a few qt_find_package calls already exist. The feature value is also saved to QtBuildInternalsExtra, to make sure that pkg-config is disabled whenever building another repo. System prefix adjustment is done by removing paths from CMAKE_SYSTEM_PREFIX_PATH. Ideally we would remove also /usr as a path, to match what qmake does, but that breaks find_program() calls for perl, python, etc. We have to make sure that qt_find_package does not look in PATH when looking for packages, which is the default behavior, because PATH on macOS most likely contains /usr/local. One last curiosity for future generations is that CMake 3.18+ has merged a change to prioritise SDK locations over regular /usr/lib. Fixes: QTBUG-85261 Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Add meta-target host_tools to easily build just the toolsAlexandru Croitor2020-06-261-0/+7
| | | | | | | | | | | A developer could write 'ninja host_tools' to build the qtbase tools and their dependencies, and then configure another cross-compiling build dir pointing to the previous host build. This shortens the workflow for cross-building when working in qtbase. Change-Id: I69e70d23ce9df8669bcadf326d0586f097e5cb21 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't reset install prefix upon standalone test reconfigurationAlexandru Croitor2020-06-081-12/+4
| | | | | | | | | | | | | | | | | | | | CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT might be empty on the first configuration, but because QtBuildInternalsExtra sets the CMAKE_INSTALL_PREFIX, a second reconfiguration of a test would stop setting the fake install prefix. After some further consideration, there's no need to set the local fake prefix conditionally, we can always do it (unless explicitly opted out). This makes sure that a reconfiguration of a test doesn't suddenly install into the Qt prefix again. Amends 37b132cd4e081821ddc261d24abe8f914123547a Task-number: QTBUG-84346 Change-Id: Ic61aefe18418658455d8cdb9ebe6bcbcb8d67c99 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* cmake: quote paths to prevent issues when no install prefix is setJean-Michaël Celerier2020-06-051-1/+1
| | | | | Change-Id: Ifa7f1ef70c4893e10cb4ce9a54d8a0806d19be93 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix standalone tests to work properly on reconfigurationAlexandru Croitor2020-06-042-17/+25
| | | | | | | | | | | | | | | | | And also fix qt-cmake-standalone-test to work for prefix builds. The gist of it is that we have to protect tests not to be installed into the Qt install prefix, but we also have to make sure that the CMAKE_INSTALL_PREFIX is not changed globally (via cache value), so that reconfiguration still works. This took way too long to figure out. Amends d6272d774c7415186aa398e59f234d0073458072 Fixes: QTBUG-84346 Change-Id: I18c29574c9957fe05b86f701c8c14ec07e0f045b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Make build system of installed Qt more relocatableAlexandru Croitor2020-05-071-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Fix the setup for html_docs and qch_docsVenugopal Shivashankar2020-04-301-2/+2
| | | | | | | | | | | Traditionally, these make targets generated HTMLs and QCH only. This change fixes the dependency for these targets to ensure that behavior. Fixes: QTBUG-83877 Change-Id: Ic7c8afe5853d33fc4cc4cfd996f87e5f65df31ed Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
* CMake: Fix usage of correct install prefix for standalone testsAlexandru Croitor2020-04-301-2/+15
| | | | | | | | | | | Previously configuration of standalone tests might have failed due to CMake trying to create files in the /usr/local default prefix. Make sure to use a fake prefix in the binary dir instead, unless another prefix is explicitly specified. Change-Id: Icfcb32285aa5596abf1a918396b26673880a8d27 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Allow sqldriver plugins to be built as standaloneLeander Beernaert2020-04-241-0/+8
| | | | | | | | | | | | | This patch allows all the sqldrivers to be built as a standalone project. It is not possible to build each plugin separately due to the configuration features definition being located in the sqldriver's folder CMakeLists.txt. In other words, the project needs to be generated from the src/plugins/sqldrivers/CMakeLists.txt file. Fixes: QTBUG-82962 Change-Id: If41c7e3827589391830a894a9c998d2e56239562 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add qt6_add_plugin public APILeander Beernaert2020-04-221-0/+1
| | | | | | | | | | | | | | | This patch adds a publicly callable qt6_add_plugin() API to create plugins. This API is meant to cover cases such as the plugandpaint example. This patch also renames qt_add_plugin to qt_internal_add_plugin in order to avoid clashes with the public API. To avoid breaking the existing projects, a compatibility wrapper function is enabled by default unless QT_DISABLE_QT_ADD_PLUGIN_COMPATIBILITY is specified. Fixes: QTBUG-82961 Change-Id: If5b564a8406c90434f1bdad0b8df76d3e6626b5f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make sure not to use the Qt prefix for standalone testsAlexandru Croitor2020-04-172-0/+19
| | | | | | | | | We don't want people accidentally installing tests into the Qt prefix. Change-Id: Ic99492559875f753897a83af162253cac846a8a5 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Handle automatic rpath embedding correctlyAlexandru Croitor2020-04-171-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 e835a6853b9c0fb7af32798ed8965de3adf0e15b Task-number: QTBUG-83497 Change-Id: I3510f63c0a59489741116cc8ec3ef6a0a7704f25 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Autodetect Objective-C support only on macOSAlexandru Croitor2020-04-071-1/+6
| | | | | | | | | | | | On Android, check_language() reports that the languages are supported, but enable_language fails afterwards. On Linux it causes issues with the PCH. The PCH file might contain a Clang pragma, even though the C++ compiler is GCC. Presumably due to finding a Clang Objective-C compiler. Change-Id: I1b4c54459772c089e7f6350872c87af52ad72a37 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Adjust PCH support for multi-arch iOS buildsAlexandru Croitor2020-04-031-0/+18
| | | | | | | | | | | | | | | | | | 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>
* CMake: Provide script to configure and build one or more testsAlexandru Croitor2020-03-232-3/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch there were a few ways to build tests - Configure all tests as part of the repo build - Configure all tests as part of the repo build, but don't build tests by default (-DQT_NO_MAKE_TESTS=ON) - Configure all tests as a standalone project in a separate build dir using -QT_BUILD_STANDALONE_TESTS=ON All of the above incur some time overhead due to the necessity of configuring all tests. Sometimes you just want to build ONE test (or a few). To facilitate that use case, a new shell script called bin/qt-cmake-standalone-test(.bat) can now be used to configure and build one or more tests. The script takes one single argument pointing to the desired test project path and configures a generic template project that sets up all the necessary Qt CMake private API, afterwards calling add_subdirectory on the passed in project. Example $ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image/qicon or $ path/to/qt/bin/qt-cmake-standalone-test ./tests/auto/gui/image After that, simply run 'ninja && ctest' to build and run the test(s). This is the CMake equivalent of calling qmake on a test .pro file (or on a tests SUBDIRS .pro file) There are 3 details worth mentioning. Due to the add_subdirectory call, the built artifacts will not be in the top-level build dir, but rather in a nested build_dir. The script currently can't handle more than one argument (the path to the project), so you can't pass additional -DFoo=bar arguments. If a test uses a 3rd party library (like Threads::Threads) which was not a public dependency for any of the Qt modules, configuration will fail saying that the target was not found. Perhaps we should consider recording these packages when generating the StandaloneConfig.cmake files. Change-Id: Icde6ecb839341d34f341d9a19402c91196ed5aa0 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add global / top-level docs targetsAlexandru Croitor2020-03-181-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously you could use either module-specific or repo-specific 'docs' targets. For example 'ninja html_docs_qtbase' or 'ninja html_docs_Core'. Now there's a global / top-level target called 'docs', so 'ninja docs' works. For super builds it will build the documentation of all configured repositories. For a single repo build, it's equivalent to calling 'ninja docs_repo_name'. Also for consistency, add the "docs_Core" target, which was missing before. So now a 'docs' target exsits for repo names AND targets. New global target names are - docs - prepare_docs - generate_docs - html_docs - qch_docs - install_html_docs_docs - install_qch_docs_docs - install_docs_docs Amends 0095ff4e0659906595d281b37c3b7f89e37250af Change-Id: I686be1e0962e40cbce860e8ac2cabb056b360ac2 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* CMake: Fix incorrect argument in QtBuildInternalsAndroidAlexandru Croitor2020-03-121-2/+2
| | | | | | | | Uncovered while building qtdeclarative. Change-Id: If1a36f2640a3a5d765e7ca74b0ba1d39ef2a18f0 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-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | 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: Use correct C++ standard flag when building standalone testsAlexandru Croitor2020-02-181-0/+5
| | | | | | | | | | | | | | Before the patch we set the standard flags in two places: - once when building qtbase - and always when including QtSetup (for every repo that is built) This change makes sure to also set the correct standards flag when building standalone tests, because QtSetup is called to early in that case. Change-Id: Iad130b731e9eb9605bb91637364c33fdd49ce3cb Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Lars Knoll <lars.knoll@qt.io>
* Merge remote-tracking branch 'origin/5.15' into devLiang Qi2020-02-131-1/+1
| | | | | | | | | | | | | | | | | | | | Conflicts: examples/widgets/graphicsview/boxes/scene.h src/corelib/Qt5CoreMacros.cmake src/corelib/Qt6CoreMacros.cmake src/network/ssl/qsslsocket.cpp src/network/ssl/qsslsocket.h src/platformsupport/fontdatabases/windows/qwindowsfontenginedirectwrite.cpp src/testlib/CMakeLists.txt src/testlib/.prev_CMakeLists.txt tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp Disabled building manual tests with CMake for now, because qmake doesn't do it, and it confuses people. Done-With: Alexandru Croitor <alexandru.croitor@qt.io> Done-With: Volker Hilsheimer <volker.hilsheimer@qt.io> Change-Id: I865ae347bd01f4e59f16d007b66d175a52f1f152
* Implement qtbase fixes for superbuildsJean-Michaël Celerier2020-01-081-36/+13
| | | | | | Change-Id: I0d3445cf0740e3925fa9342dac4d07892518afe5 Reviewed-by: Qt CMake Build Bot Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Add custom targets for documentationLeander Beernaert2019-12-181-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | Adds custom targets which take care of generating and installing documentation files. Every module has a global set of targets suffixed with the module name in order for them to be unique when we implement super builds. The targets are the same as the list below, but replace ${target} with the module's name. Eg.: docs_qtbase. For every target which has an qt_add_docs() call, we now create the following set of custom targets: * docs_${target} * html_docs_${target} * qch_docs_${target} * prepare_docs_${target} * generate_docs_${target} * install_docs_${target} * install_html_docs_${target} * install_qch_docs_${target} Fixes: QTBUG-75859 Change-Id: Ie84cb9a2dedbe7333d9a84f4d73383442deca477 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Don't include standalone tests config file if none existsAlexandru Croitor2019-11-131-1/+1
| | | | | | | | | | | Some repos like qtimageformats don't generate a config file for standalone tests because the repo creates no modules. Amends de3a806def4b9a754825a2233c9d4952a9b2d0eb Change-Id: Id42338804605a883f975feb5dd81eda5acc6e687 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Build test/manual if it contains a CMakeLists.txtLeander Beernaert2019-11-121-0/+3
| | | | | | | Change-Id: Ibada60b0902f9c6a6a7284489a56106e0021a9de Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add support for -nomake-tests and -nomake-examples equivalentsAlexandru Croitor2019-11-081-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-39/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix interface library issues on AndroidAlexandru Croitor2019-11-081-0/+4
| | | | | | | | | | | Don't call qt_android_dependencies for interface libraries. Also make sure not to set properties which don't start with INTERFACE_ prefix. Change-Id: I0afdffd34c9aebe0d7ac4731b57dd4d505f84570 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
* Add support for benchmark conversionLeander Beernaert2019-11-041-1/+1
| | | | | | | | | | | | | 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>
* Include QtPlatformSupport as part of find_package(Qt6BuildInternals)Alexandru Croitor2019-09-271-7/+11
| | | | | | | | | | | 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>
* cmake: Include repo-specific setup filesJoerg Bornemann2019-09-231-0/+10
| | | | | | | | | | | This is useful for providing private CMake API which is not part of QtBase. Also, fix the setup files to be included when building standalone tests. The old ${PROJECT_NAME}Setup.cmake file inclusion will be removed once all usages are adjusted. Prompted-by: Alexandru Croitor <alexandru.croitor@qt.io> Change-Id: I5bc2bca7371660c00b0301e94d025a29b68d6975 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix examples find_package calls to work in prefix buildsAlexandru Croitor2019-09-211-1/+6
| | | | | | | | | | | | | | | | | | | To build examples as part of a non-installed Qt prefix build, not-yet-installed Config files need to be found by find_package() calls inside example projects. Facilitate that by propagating the CMAKE_PREFIX_PATH and QT_EXAMPLES_CMAKE_PREFIX_PATH paths in all relevant find_package() calls where NO_DEFAULT_PATH is used. Also adjust the inclusion of the QtFeature.cmake file to be relative to the qt6 directory, rather than the current list directory. This is needed to successfully find the file when parsing a Config file from a non-installed build directory. Change-Id: I36031279628f1f7741d8f4d7571484a6545227f7 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* cmake: Init uic only if Qt::Widgets is a targetJoerg Bornemann2019-09-201-1/+4
| | | | | | | | | | Otherwise we get errors like the following in non-gui projects: Error evaluating generator expression: $<TARGET_FILE:Qt6::uic> No target "Qt6::uic" Change-Id: I8a3a6f8ec5e5c1c3d1f73369c5739a321c64bfbb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Print build instructions when configuring qtbaseAlexandru Croitor2019-09-171-0/+25
| | | | | | | | This is similar to how we show the instructions when configuring in qmake land. Change-Id: Iabd28acc3d74fd0175eab812a412744dac89e6f6 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Use $$source_path/qtbase/cmake modules when doing non-prefix buildsAlexandru Croitor2019-09-061-3/+14
| | | | | | | | | | | | | | | | | | | This is similar to qmake, where the .prf files from the source location of qtbase/mkspecs are used in a non-prefix build. This means that if a developer changes the source QtBuild.cmake, and then runs make in qtdeclarative, cmake will reconfigure qtdeclarative because the timestamp of QtBuild.cmake changed. Before this change you first had to make && make install in the qtbase build directory, before qtdeclarative saw the modified QtBuild.cmake. This change also makes the module paths be prepended to CMAKE_MODULE_PATH instead of appended, which means they will take precedence to any path provided via command line. Change-Id: I9178d5183a95b3b67bfe1b1fe91d3d3371ffe5c5 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Disable Examples in static buildLeander Beernaert2019-09-031-1/+1
| | | | | | | | | Do not build examples in static builds as they are not prepared for this configuration. Change-Id: Ia0fd0a6cdfa3733bf13eb2ca8398668f26c0bedf Reviewed-by: Qt CMake Build Bot Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Decide whether to build tools when doing a standalone test buildAlexandru Croitor2019-09-021-0/+1
| | | | | | | | Needed for qtdeclarative standalone tests. Change-Id: Ie012528d0d553cb63c2d79f3ded35e45872ee89a Reviewed-by: Simon Hausmann <simon.hausmann@qt.io> Reviewed-by: Qt CMake Build Bot
* Update Android build configurationLeander Beernaert2019-08-301-12/+17
| | | | | | | | | | | | | | | | | | Update Android build configuration to be compatible with the multi-arch android build patch to qmake. We can now build and generate the apk correctly. Executing on the device/simulator will only work once the latest changes from 5.14 have been merged in. We now replace target suffix with ${CMAKE_ANDROID_ARCH_ABI}.[so|a] so we don't have to deal with handling targets which might have any of the OUTPUT_NAME properties set. The dependency and deploy settings generation has also been updated to append the file contents to a string and then do a single file write at the end. Change-Id: Id3c5bd0428141ecaf962124a100390e3a4e41feb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add missing qml-root-path for AndroidLeander Beernaert2019-08-281-1/+3
| | | | | | | | | | | | Add missing qml root path variable in the deployment configuration file. Not having this variable will cause androiddeployqt not use the qml dependency scanner to package all relevant dependencies. This patch also fixes QT_ANDROID_BUNDLED_FILES files not being processed. Change-Id: I5bca33cdbb57098f283b38516b777571806da9e5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix Android build for other Qt modulesLeander Beernaert2019-08-161-1/+1
| | | | | | | Install missing QtBuildInternalsAndroid to installation path. Change-Id: I6141ff72b57a6445f1718bc17d64a7ed59a91620 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Perform check for tool builds before srcLeander Beernaert2019-08-071-2/+3
| | | | | | | | | | Perform the test whether tools should be built before entering the source directory of a project. In QtDeclarative this would result in a configuration error since the tools are used while building everything under src. Change-Id: I33ce2cb317ef221836d696654f3bb4e39db47e54 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Android: Final changes for APK generationLeander Beernaert2019-06-262-0/+210
| | | | | | | | | | | | | | | | | | | | Generate the ${MODULE}-android-dependencies.xml for the androiddeployqt tool. This will ensure all the right plugins and dependencies are packaged when generating the apk. This change also changes the visibility for executable to default/public. Not having this will cause the application to crash as we can't locate main() in the executable (shared library). Additionally pro2cmake conversion script has been updated to perform the required conversions for the Android settings. Finally, the 6 projects in QtBase that have Android dependencies have been updated with the new script and the step that produces the xml files in run at the end in QtPostProcess.cmake. Change-Id: I9774ba1b123bc11cae972fa37054ef2c51988498 Reviewed-by: Simon Hausmann <simon.hausmann@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
* Try to find Test package before calling add_subdirectory(src)Alexandru Croitor2019-06-131-1/+7
| | | | | | | | | | | in qt_build_repo(). This is important for qtdeclarative for example, which builds QmlTest functionality in ./src, and thus needs Test lib to be available. Change-Id: I84326d79844526f2f177c19de30bab0c858773e3 Reviewed-by: Qt CMake Build Bot Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* Automatically find apple frameworks when building a repoAlexandru Croitor2019-06-131-0/+3
| | | | | | | | | Instead of doing it just in qtbase/src, we need to do it for all repos before building ./src. Change-Id: I57f226b849cd5370ffbbbea8a694697d400957a4 Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Liang Qi <liang.qi@qt.io>
* Fix linking of examplesSimon Hausmann2019-06-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Provide add_qt_gui_executable() as function in our public API that takes care of automaticWinMain linkage. We can use this in the future to encapsulate similarplatform-specific behavior and adjustments, such as module generation onAndroid. In order for the examples to see the function in Qt5CoreMacros, three more additional fixes were required: * Do the build_repo_end() call _before_ attempting to build the examples, as we need the build_repo_end() to include QtPostProcess and complete the creation of all the target config files. Otherwise the find_package() calls in the examples see something incomplete. * Add more QT_NO_CREATE_TARGET guards * Always call find_dependency on the dependencies, regardless of the target creation mode. This way a find_package(Qt5 COMPONENTS Widgets) will still load Qt5CoreMacros. Change-Id: I03ce856e2f4312a050fe8043b8331cbe8a6c93e6 Reviewed-by: Qt CMake Build Bot Reviewed-by: Leander Beernaert <leander.beernaert@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>