summaryrefslogtreecommitdiffstats
path: root/tests/auto/cmake/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* Add the support for custom definitions to the qt_manual_moc functionAlexey Edelev2024-02-231-0/+2
| | | | | | | | | | | The function now support two new arguments: - DEFINITIONS, which allows specifying the custom definitions - TARGETS, the list of targets thart will be used to collect the [INTERFACE_]INCLUDE_DIRECTORIES and COMPILE_DEFINITIONS. Task-number: QTBUG-104898 Change-Id: I3f67537057f91a97597788f1bd4db6904bac6d9c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add test for configuring a standalone testAlexandru Croitor2024-02-081-0/+6
| | | | | | | | | | | | | | | A standalone test is one that uses find_package(Qt6BuildInternals REQUIRED COMPONENTS STANDALONE_TEST) in its project code. To ensure we don't accidentally regress this feature, test it as a cmake test. Also run test, this somewhat covers testing qt_internal_add_test. Pick-to: 6.5 6.6 6.7 Change-Id: Ia9f27eef2bd7bd5bb57b96e553304924db252365 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Add plugins of imported QtModules to the _qt_plugins propertyAlexey Edelev2024-02-061-0/+3
| | | | | | | | | | | | | | | | | | This covers the following use case: QtModuleX is pre-built and installed, it's imported. The plugin has a PLUGIN_TYPE that is associated with QtModuleX and is built with application that links QtModuleX. When deploying the application it's expected that the plugin is deployed, as the one that belongs to the linked QtModuleX. This ensures that we udpate the internal _qt_plugins property that is used in the __qt_internal_collect_plugin_targets_from_dependencies function. Pick-to: 6.5 6.6 6.7 Change-Id: I9824351ebab5a24509800da4db69f1e282a35884 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Introduce QTP0003 which controls the BUILD_SHARED_LIBS impact on user projectsAlexey Edelev2024-02-011-0/+1
| | | | | | | | | | | | | | | | | | | Since 6.7 we consider the BUILD_SHARED_LIBS when creating libraries using Qt CMake API. This change may affect the user projects that rely on the old strategy of selecting the default library type. To preserve the old behavior this change introduces the QTP0003 policy that allows user to control whether the BUILD_SHARED_LIBS should or shouldn't be considered in library creation process. The policy doesn't affect Qt repos, we assume that we want the NEW behavior by default. Fixes: QTBUG-121707 Pick-to: 6.7 Change-Id: I4bcfbd8966839731624e3f7ef9e0d6bb2782ac50 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Leena Miettinen <riitta-leena.miettinen@qt.io>
* qt6_wrap_cpp: Add .moc generationOrkun Tokdemir2024-01-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | When a `.moc` file is included in a source file and that source passed to `qt_wrap_cpp`, Users should add the generated `.moc`s path to the target's include path. Since we don't share anything about the output path of generated files by `qt_wrap_cpp`, it makes sense to add in inside `qt_wrap_cpp`. And also, the generated `.moc` file is added to target's source to complete the dependency graph. Otherwise, Users need to get output variable and pass it to target's sources. * Update docs * Add test [ChangeLog][Build System] qt_wrap_cpp will accept .cpp files from now on. When .cpp a file is passed to qt_wrap_cpp, TARGET parameter becomes required. Generated .moc files are added to target's sources inside qt_wrap_cpp. That's why the output parameter will not contain generated .moc files. Fixes: QTBUG-113402 Change-Id: I54dd2b1ff8e5c9ba457b1eb4f73b0a8190d9c659 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Add autotest for the config condition evaluatorJoerg Bornemann2023-09-211-0/+2
| | | | | | | | | | This serves as regression test for future fixes of the config condition evaluator. Task-number: QTBUG-117053 Change-Id: Ib05fe5f5fb6aa2d440ecbc8affaf99b040553c06 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
* CMake: Place resources into static libraries, not object librariesAlexandru Croitor2023-08-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Take 2. Re-land previously reverted commit, due to not handling resource names that are not valid c++ identifiers. Now we sanitize the resource names just like rcc does by replacing non-alphanumeric characters with underscores. Original commit message. During the Qt 5 -> Qt 6 and qmake -> CMake porting time frame, it was decided to keep resources in an object file (object library), rather than putting them directly into a static library when doing a static Qt build, so that the build system can take care of linking the object file directly into the executable and thus not forcing project developers to manually initialize resources with the Q_INIT_RESOURCE() macro in project code. This worked for most qmake and cmake projects, but it created difficulties for other build systems, in the sense that these projects would have to manually link to the resource object files, otherwise they would get link time errors about undefined resource symbols, assuming they kept the Q_INIT_RESOURCE() calls. If the project code didn't contain Q_INIT_RESOURCE calls, the situation would be even worse, the linker would not error out, and the missing resources would only be discovered at runtime. It's also an issue in CMake projects that try to link to the library files directly instead of using the library target names, which means the object files would not be automatically linked in. Many projects try to do that because we don't yet offer a convenient way to install libraries and reuse them in other projects (the SDK case), so projects end up shipping only the libraries, without the resource object files. We can improve the situation by moving the resources back into their associated static libraries, and only keeping a static initializer as a separate object file / object library, which references the actual resource initializer symbol, to ensure it does not get discarded during linking. This way, projects that link using targets get no behavior difference, whereas projects linking to static libraries directly can still successfully build as long as their sources have all the necessary Q_INIT_RESOURCE calls. To ensure the resource symbols do not get discarded, we use a few new private macros. We declare the resource init symbols we want to keep as extern symbols and then assign the symbol addresses to volatile variables. This prevents discarding the symbols with the compilers / linkers we care about. It comes at the cost of an additional static initializer per resource, but we would get the same + a bigger performance hit if we just used Q_INIT_RESOURCE twice (once in the object lib and once in project code), which internally needs to traverse a linked list of all resources to check if a resource was initialized or not. For GHS / Integrity, we also need to use a GHS-specific pragma to keep the symbols, which we currently use in qtdeclarative to ensure qml plugin symbols are not discarded. The same macros will be used in a qtdeclarative change to prevent discarding of resources when linking to static qml plugins. A cmake-based test case is added to verify that linking to static libraries directly, without linking to the resource initializer object libraries, works fine as long as the project code calls Q_INIT_RESOURCE for the relevant resource. This reverts commit bc88bb34caf1185a25eda77ee022843c0ca988b0. Fixes: QTBUG-91448 Task-number: QTBUG-110243 Change-Id: Idce69db0cf79d3e32916750bfa61774ced977a7e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Revert "CMake: Place resources into static libraries, not object libraries"Alexandru Croitor2023-08-091-1/+0
| | | | | | | | | | This reverts commit ce8874fc3b0bab2066080315c8774b30c038862c. Reason for revert: Doesn't handle resource names that are invalid identifiers Change-Id: Idf24bd9797284ce9de382a8e233d56c799a09099 Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Place resources into static libraries, not object librariesAlexandru Croitor2023-08-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During the Qt 5 -> Qt 6 and qmake -> CMake porting time frame, it was decided to keep resources in an object file (object library), rather than putting them directly into a static library when doing a static Qt build, so that the build system can take care of linking the object file directly into the executable and thus not forcing project developers to manually initialize resources with the Q_INIT_RESOURCE() macro in project code. This worked for most qmake and cmake projects, but it created difficulties for other build systems, in the sense that these projects would have to manually link to the resource object files, otherwise they would get link time errors about undefined resource symbols, assuming they kept the Q_INIT_RESOURCE() calls. If the project code didn't contain Q_INIT_RESOURCE calls, the situation would be even worse, the linker would not error out, and the missing resources would only be discovered at runtime. It's also an issue in CMake projects that try to link to the library files directly instead of using the library target names, which means the object files would not be automatically linked in. Many projects try to do that because we don't yet offer a convenient way to install libraries and reuse them in other projects (the SDK case), so projects end up shipping only the libraries, without the resource object files. We can improve the situation by moving the resources back into their associated static libraries, and only keeping a static initializer as a separate object file / object library, which references the actual resource initializer symbol, to ensure it does not get discarded during linking. This way, projects that link using targets get no behavior difference, whereas projects linking to static libraries directly can still successfully build as long as their sources have all the necessary Q_INIT_RESOURCE calls. To ensure the resource symbols do not get discarded, we use a few new private macros. We declare the resource init symbols we want to keep as extern symbols and then assign the symbol addresses to volatile variables. This prevents discarding the symbols with the compilers / linkers we care about. It comes at the cost of an additional static initializer per resource, but we would get the same + a bigger performance hit if we just used Q_INIT_RESOURCE twice (once in the object lib and once in project code), which internally needs to traverse a linked list of all resources to check if a resource was initialized or not. For GHS / Integrity, we also need to use a GHS-specific pragma to keep the symbols, which we currently use in qtdeclarative to ensure qml plugin symbols are not discarded. The same macros will be used in a qtdeclarative change to prevent discarding of resources when linking to static qml plugins. A cmake-based test case is added to verify that linking to static libraries directly, without linking to the resource initializer object libraries, works fine as long as the project code calls Q_INIT_RESOURCE for the relevant resource. Fixes: QTBUG-91448 Task-number: QTBUG-110243 Change-Id: I39c325aac91e36d53c3576a39f881949c3b21e3f Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Fix handling of QT_PATH_ANDROID_ABI_xxxx in android multi-abi testsAlexey Edelev2023-07-041-1/+1
| | | | | | | | | Fix 'IN_LISTS' typo, should be IN LISTS. Pick-to: 6.5 6.6 Change-Id: Ia0bd1bf45922b2c9c1779e03b40dad6eab97eef1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* tests: Remove remains of qmake conversion from CMakeLists.txt filesFriedemann Kleint2023-02-171-2/+0
| | | | | | | Pick-to: 6.5 Change-Id: I8d106554bb86ac1ec9bb7a4083de4c376bcbab1d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add forwarding of CMake variables to ABI-specific external projectsAlexey Edelev2022-12-081-1/+39
| | | | | | | | | | | | The 'QT_ANDROID_MULTI_ABI_FORWARD_VARS' variable allows to forward variable values to ABI-specific external projects. The variable accepts names of variables that needs to be forwarded. Pick-to: 6.4 Task-number: QTBUG-107893 Change-Id: Iaa4fa7e98ad0df956d90f91e157edb561183c795 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Move Some of the Private CMake Helper Scripts from `bin/` to `libexec/`Amir Masoud Abdol2022-12-051-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | After this change, private CMake scripts are mostly live in `libexec/`, except the `qt-cmake` which will stay in `bin/`. This doesn't affect the Windows configuration. - `qt-cmake` stays in `bin/` - `qt-configure-module` moves into `libexec/` - `qt-cmake-private` moves into `libexec/` - `qt-cmake-private-install.cmake` moves into `libexec/` - `qt-cmake-standalone-test` moves into `libexec/` - `qt-internal-configure-test` moves into `libexec/` In cases where `QT_GENERATE_WRAPPER_SCRIPTS_FOR_ALL_HOSTS` is set to ON, e.g., ANDROID, WASM, both Batch and Bash files will be generated and placed in `bin/` and `libexec/` accordingly; in both cases, qt-cmake and qt-cmake.bat will be in `bin/` anyway. [ChangeLog][CMake] The private Qt CMake scripts, i.e., qt-configure-module, qt-cmake-private, qt-cmake-private-install.cmake, qt-cmake-standalone-test and qt-internal-configure-test were moved into $prefix/libexec on Unix platforms. Fixes: QTBUG-107621 Change-Id: Ic4f4ec85f64d2ede0e208bca928959e30be906a6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add auto test for qt_add_resources dependency rebuildingAlexandru Croitor2022-12-021-0/+1
| | | | | | | | | | | | Make sure that touching any file that is part of a qrc resource actually rebuilds the resource and the target that depends on the resource. Pick-to: 6.4 Task-number: QTBUG-107687 Task-number: QTBUG-108113 Change-Id: I1153dc13fee44ffe59d2685a8cb33303538b026c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* tests: fix configuring with -no-feature-guiJohannes Kauffmann2022-10-291-5/+4
| | | | | | Pick-to: 6.2 6.4 Change-Id: I99765d38c9c37f1fe17b15f7736e4c78c7ffac20 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Make the `PREFIX` Parameter of the `qt_add_resources` OptionalAmir Masoud Abdol2022-10-251-0/+1
| | | | | | | | | | | | | | | | The `rcc_PREFIX` will be set to `/` if it is not passed to the function and it is not defined in `QT_RESOURCE_PREFIX`. I also removed an unnecessary check of the `rcc_PREFIX`. [ChangeLog][QtCore][CMake] The `PREFIX` parameter of the `qt_add_resources` is now optional. If not passed, and `QT_RESOURCE_PREFIX` is not defined, `/` will be used as the path prefix. Fixes: QTBUG-104938 Change-Id: I6524ab5dc54f035272e4c2e3154eb67591efb650 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Set RPATH of deployed plugins on LinuxJoerg Bornemann2022-10-151-5/+10
| | | | | | | | | | | | | | | | | | | | When deploying into some directory structure where CMAKE_INSTALL_LIBDIR is different from Qt's lib dir, we need to set the RPATH of installed plugins such that Qt libraries are found. We do this using CMake's undocumented file(RPATH_SET) command and pray that this command is safe to use across current and future CMake versions. For CMake versions < 3.21, we use patchelf, which must be installed on the host system. The adjustment of rpaths can be turned on explicitly by setting QT_DEPLOY_FORCE_ADJUST_RPATHS to ON. The usage of patchelf can be forced by setting QT_DEPLOY_USE_PATCHELF to ON regardless of the CMake version. Change-Id: I62ced496b4c12bf6d46735d2af7ff35130148acb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Don't set QT_PLUGIN_PATH in the deployment test's run environmentJoerg Bornemann2022-10-151-0/+1
| | | | | | | | | | | | | Otherwise we don't properly test whether the deployed executable can run without adjusting the environment. We temporarily adjust the test_widgets_app_deployment test and set CMAKE_INSTALL_LIBDIR to make the test pass. It would now fail on Linux distros where CMAKE_INSTALL_LIBDIR defaults to "lib64" but Qt is built with lib dir "lib". The next commit removes this hack. Change-Id: I63c79ef1ee23ffaeed881337fde6e9d889ecc0fe Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Replace the syncqt.pl script with syncqt toolAlexey Edelev2022-09-271-18/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | syncqt.pl adds an extra dependency on perl when building Qt. Modern C++ provides the convenient cross-platform way to access a filesystem and to use regular expressions, so we may replace the perl script with C++ application. The syncqt executable is built at configure time and installed as QtCore tool. It's running at configure time to deliver the required header files for IDE to build a consistent code model and at the build time to keep tracking changes in header files and generate the missing aliases without reconfiguring. 'syncqt' only parses header files from a CMake build tree, so the resulting Qt installation only contains interfacing headers that belong to the platform that Qt is built for. 'sync.profile' files are not used as the 'source of truth' for sync qt procedure anymore, all the necessary information is taken from either CMake files at configure time or from the module header files while parsing them. syncqt.pl is still in place since it's required as fallback solution for a smooth transition to the new syncqt implementation for all qt repositories. This patchset only enables the C++ based syncqt for 'qtbase' repository. From the performance perspective C++ version works faster then perl script, also the configure time is reduced significally on subsequent reconfigurations - up x2 times faster when re-configuring repository, but it also takes time to compile the tool itself the first time. Numbers for qtbase: syncqt.pl syncqt.cpp initial: 0m16,035s 0m20,413s reconfig: 0m6,819s 0m3,725s The syncing procedure can be run separately for each module using <ModuleName>_sync_headers targets. The 'sync_headers' target can be used to sync all the modules at once. Task-number: QTBUG-87480 Task-number: QTBUG-103196 Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add Linux support to qt_deploy_runtime_dependenciesJoerg Bornemann2022-09-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | Before this change, qt_deploy_runtime_dependencies supported Windows and macOS only. We add a generic deployment method implemented in cmake-language with file(GET_RUNTIME_DEPENDENCIES). This deployment method is now enabled for shared builds on Linux. The file(GRD) command requires that the EXECUTABLE argument points to the executable in the build directory. Only libraries in Qt's installation directory are considered for deployment. This includes Qt's own libraries and also things like libicu*.so we're shipping with the installer. Unlike macdeployqt and windeployqt, the generic qt_deploy_runtime_dependencies does not yet support deploying translations. We will catch up on this in a later commit. Change-Id: Iea23abcdba774d4c1885c8d2c243eb3e48fb7fae Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Change the license of all CMakeLists.txt and *.cmake files to BSDLucie Gérard2022-08-231-1/+1
| | | | | | | Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Add simple widgets qmake iOS build testAlexandru Croitor2022-08-171-0/+18
| | | | | | | | | | | | | | | Build a simple widgets qmake project when targeting iOS in the CI. This ensure we don't introduce basic regressions in the .pri / .prl file generation. Make sure to target the ios simulator, so we don't require any code signing or provisioning profiles. Pick-to: 6.4 Fixes: QTBUG-96058 Change-Id: I1a5564e838a5ce3cac89a37a5a4ddee74d3400f3 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Support big resources in qt_add_resourcesJoerg Bornemann2022-08-091-0/+4
| | | | | | | | | | [ChangeLog][CMake] The target-based variant of qt6_add_resource gained the option BIG_RESOURCES. This can be used instead of qt6_add_big_resources, which is not target-based. Fixes: QTBUG-100268 Change-Id: Ib3fa783cbfbfd10f59c2f952bc88508a91f25e26 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix mockplugins test not to fail in a non-prefix buildAlexandru Croitor2022-08-051-5/+10
| | | | | | | | | | Explicitly running the install step would fail in a non-prefix build. Do it conditionally on the no_prefix feature. Pick-to: 6.4 Change-Id: I78cd63f51c499a0df451b08290c6dfc84e52666c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Add license headers to cmake filesLucie Gérard2022-08-031-0/+3
| | | | | | | | | | | | CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Add deployment auto testAlexandru Croitor2022-03-161-0/+19
| | | | | | | | | | | | | | | | Add a cmake test that builds a simple widgets application, installs it, in a shared Qt build deploys the runtime dependencies and then runs it to confirm that the app works. With a static Qt, the installation of the runtime dependencies is skipped, but the app should still run. The test is expected to pass only when targeting Windows and macOS (both when using shared and static Qt). Pick-to: 6.3 Task-number: QTBUG-98545 Change-Id: I41b616e1e1fc463d57c64be9273ed4dc755e9187 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Fix dependency chain that collects the metatype json filesAlexey Edelev2021-12-021-0/+2
| | | | | | | | | | | | | | | | | | | | | cmake_automoc_parser has the logic preventing the run of moc with the --collect-json parameter if metatype json files are not changed. This logic only verify if the file list is changed but not their content. This change adds a timestamp file that contains the last metatype json file timestamp that was modified during the last cmake_automoc_parser run. The logic still prevents of running 'moc --collect-json' when the list of metatype json files is not changed, but also checks if their content is no changed. Another approach it to generate the depfile that can be utilized by CMake in add_custom_command as DEPFILE argument. But this concept only works from the second build attempt because of an issue related to dyndep. Pick-to: 6.2 Fixes: QTBUG-98532 Change-Id: I713f8bfa9ae769cefe0beac0b7fa19750b00a765 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Bump almost all cmake_minimum_required calls to 3.16Alexandru Croitor2021-09-221-1/+1
| | | | | | | | | | | | Needed for subsequent change that will check and error out if the version is lower than 3.16. We do that to ensure all policies introduced by CMake up to version 3.16 have their behavior set to NEW. Pick-to: 6.2 Task-number: QTBUG-95018 Change-Id: Ieaf82c10987dd797d86a3fd4a986a67e72de486a Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* CMake: Build a subset of tests when targeting iOS in the CIAlexandru Croitor2021-08-261-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | Add infrastructure to build cmake auto tests in the CI when targeting iOS. Currently the are only CI instructions for qtbase. More work is needed to make it work for other repos. With this change, we will build a single Widgets application targeting the iOS simulator. We can't target the device SDK in the CI because signing fails due to a missing signing certificate and provisioning profile. The Coin instructions will now set a QT_BUILD_ENVIRONMENT=ci env var whose value will be checked in _qt_internal_test_expect_pass, to ensure we build for the simulator SDK when using a universal Qt. Without this, xcodebuild will try to build with the device SDK and fail to build the project. Pick-to: 6.2 Task-number: QTBUG-95839 Change-Id: Ib39c9527b107b2004746ccbdc9d9d1d658f88c76 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Disable test_QT_TESTCASE_BUILDDIR cmake build testAlexandru Croitor2021-07-221-4/+8
| | | | | | | | | | | | | | | | | | | | | CMake 3.21.0 + Ninja now pass absolute source file paths to the compiler which causes __FILE__ to be absolute and qFindTestData to ignore any QT_TESTCASE_BUILDDIR value. This causes the test to fail, because it won't find test data in the custom specified location. Disable the test for now. Amends 70464b355ec1c7007e0b1291f733e2540ba1825f Pick-to: 6.2 Task-number: QTBUG-95268 Task-number: QTBUG-95018 Change-Id: If99035e897ac1d5f153d4e19c94e4355f88970af Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Implement generating of a module cpp export headerAlexey Edelev2021-06-241-0/+2
| | | | | | | | | | Add an option that automatically generates an export header for a Qt module. The header contains only Q_DECL_EXPORT/Q_DECL_IMPORT related content, so it's not a full replacement of 'global' header files. Task-number: QTBUG-90492 Change-Id: I250d1201b11d4096b7e78e61cbf4565945fe6517 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Allow promoting the Qt libraries to be global targetsAlexandru Croitor2021-06-161-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to true so that the various imported targets created by find_package(Qt6) are promoted to global targets. This would allow a project to find Qt packages in a subdirectory scope while using those Qt targets from a different scope. E.g. it fixes errors like CMake Error at CMakeLists.txt:5 (target_link_libraries): Error evaluating generator expression: $<TARGET_OBJECTS:Qt6::Widgets_resources_1> Objects of target "Qt6::Widgets_resources_1" referenced but no such target exists. when trying to use a static Qt from a sibling scope. Various 3rd party dependency targets (like Atomic or ZLIB) are not made global due to limitations in CMake, but as long as those targets are not mentioned directly, it shouldn't cause issues. The targets are made global in the generated QtFooAdditionalTargetInfo.cmake file. To ensure that resource object libraries promoted, the generation of the file has to be done at the end of the defining scope where qt_internal_export_additional_targets_file is called, which is achieved with a deferred finalizer. Replaced all occurrences of target promotion with a helper function which allows tracing of all promoted targets by specifying --log-level=debug to CMake. Pick-to: 6.2 Fixes: QTBUG-92878 Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Implement propagation of object files to the end-point executableAlexey Edelev2021-05-271-2/+4
| | | | | | | | | | | | | | | | | | | | This proposal collects all the resource objects to the qt-specific property of the static libraries. This is done to avoid littering of other static libraries and put resource object files to the source part of the linker line when linking the end-point executable. The way we link object resource libraries is changed back to the target_link_libraries approach as we may omit using finalizers with linkers other than ld. Users may enforce finalizers by calling the qt6_enable_resource_objects_finalizer_mode function if need. Refactor tests related to the static resources. Amends ddaa7150d85624ab545ccfe098fe8b2d18241940 Task-number: QTBUG-93002 Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Resurrect test_import_plugins cmake build testsAlexandru Croitor2021-05-111-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we run tests for static Qt builds in the CI, it makes sense to restore the CMake build tests that check that static plugin importing works correctly. Resurrect the previously commented out test_import_plugins project and port the mockplugins qmake projects to CMake. mockplugins is a CMake project that uses the internal Qt CMake API to build and install some Qt modules and plugins. test_import_plugins depends on that test (via a CMake fixture) to build public projects that use those plugins. The installation of the mockplugins modules pollutes the Qt install prefix, but in the CI that only happens on the test VM, which means the release packages are not affected. Locally on a developer machine the Qt install path will be polluted, but it's not that much of a big deal. We could try and address that in a future change by using the QT_ADDITIONAL_PACKAGES_PREFIX_PATH functionality added for Conan to allow the installation of Qt packages into a non-standard prefix. Task-number: QTBUG-87580 Task-number: QTBUG-92933 Change-Id: I0841064a60a5ffba5118640d3197527a38ba6c30 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Skip building CMake build tests in a prefix in-tree configAlexandru Croitor2021-05-111-0/+16
| | | | | | | | | | | | The Qt CMake packages are not installed yet, so the CMake build projects can't find Qt and fail to configure. Skip the CMake build tests in a prefix in-tree configuration and issue a warning for informational purposes. Change-Id: Ie5cb5b9f6f1d8ec258b70528680e31c711c20f85 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* fix: The QtStartUpFunction function may be called repeatedlyJiDe Zhang2021-04-231-0/+2
| | | | | | | | | | Don't call pre routine function in qAddPreRoutine if the qt_call_pre_routines is not called Pick-to: 6.1 6.0 Task-number: QTBUG-90341 Change-Id: I0ee70561dc57b857f8b3b1cf42c9dfe0cf45bd49 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix qtbase cmake autotestJuha Vuolle2021-04-191-5/+2
| | | | | | | | | | The testcase relied on having optional packages, and that the last package in that list was found. Otherwise the version numbers of the found modules were not set. Change-Id: I76743fd029d6eed2f4b347280591e6fdaed19053 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add test of the static plugin with resourcesAlexey Edelev2021-04-121-0/+2
| | | | | | | | | | | | | | The test follows up the discussion about tests related to the static plugin resources: https://codereview.qt-project.org/c/qt/qtbase/+/341203/6/tests/auto/other/init_resources_static_plugin/CMakeLists.txt#1 It emulates the static plugin that contains resource files. Since the test already exposed few issues related to the resource object linking it makes sense to have it in test set. Change-Id: I62621c2db1eae6ae5842ba52035774a662d93423 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Specify QT_TESTCASE_BUILDDIR for Qt::Test users implicitlyAlexey Edelev2021-04-081-0/+4
| | | | | | | | | | | | | | | | | | | QT_TESTCASE_BUILDDIR was implicitly defined by Qt::Test target for library users in Qt5. By default, this definition will point to CMAKE_CURRENT_BINARY_DIR. This logic works similarly to qmake logic. From user's perspective it might be useful to not rely on standard search paths, but specify own. This can be done by setting the QT_TESTCASE_BUILDDIR property for the user's target. CMake will substute the value of the QT_TESTCASE_BUILDDIR property into the QT_TESTCASE_BUILDDIR definition. The implicit QT_TESTCASE_SOURCEDIR also seems to be useful. According to the current logic, it points to CMAKE_CURRENT_SOURCE_DIR. Fixes: QTBUG-92079 Change-Id: I8a9065f08e859c713b3c8cc08142a9ced0677770 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add the SIMULATE_IN_SOURCE argument to _qt_internal_test_expect_passAlexey Edelev2021-04-071-19/+3
| | | | | | | | | | | | | | test_QFINDTESTDATA builds the project in the source tree, this is necessary because the test requires relative paths to the source file names. This function could be useful for other tests, so it makes sense to extend the _qt_internal_test_expect_pass/fail macros to support build in the source tree. Note that, the SIMULATE_IN_SOURCE argument doesn't build the test in the existing source tree, but copies source files to the build tree first to do not litter the source directory. Change-Id: I16e790d74be2a0c5ca0593e0f88580dbe09882b9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Choose better defaults for qt_add_plugin STATIC/SHAREDAlexandru Croitor2021-04-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a recent behavior change where the public CMake API qt_add_plugin API took into account the value of BUILD_SHARED_LIBS to decide whether the plugin should be a static or shared library. Instead, use the following new behavior - If no explicit option STATIC / SHARED option is passed, default to whatever flavor Qt was built as. Aka if Qt was configured with -shared, qt_add_plugin defaults to creating shared plugins. If it's a -static Qt, create static plugins. - If an explicit STATIC / SHARED option is set, override the default computed value with the given value. As a result BUILD_SHARED_LIBS does not affect Qt plugins anymore. This is more in line with Qt expectations. Add SHARED as a new valid option to pass to qt_add_plugin (it wasn't before). Add tests to check for the above behavior. Amends aa4a1006cbccbc180c600f9b4dc9e882bb5ed5ca Pick-to: 6.1 Fixes: QTBUG-92361 Task-number: QTBUG-88763 Change-Id: Iae806024ddd5cf10cfe58ddbcebd2818084b0bd7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Rework the failure macros in the Qt CTest kitAlexey Edelev2021-03-171-4/+4
| | | | | | | | | | | The _qt_internal_test_expect_fail macro fails when the test fails during the configuration step. Rename this macro to _qt_internal_test_expect_build_fail and add the _qt_internal_test_expect_fail macro that expects inverted test result. Change-Id: I4635e99152f7a32f5c48202e84fec59800453d34 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix qt_add_big_resources with namespace buildsAlexey Edelev2021-01-191-2/+1
| | | | | | | | | | | | Add INTERFACE_COMPILE_DEFINITIONS of Qt6::Core to generated rcc object libraries. This propagates QT_NAMESPACE definition to the object library. Fixes: QTBUG-85620 Change-Id: I252d1aaee7b19a49bc321fdd271a5d85a34bf67f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Modify test_QFINDTESTDATA to not leave files in source treeAndreas Buhr2020-12-091-6/+9
| | | | | | | | | | | | | | | test_QFINDTESTDATA is a test which is built and run in the source tree. It tests usage of relative paths of the Ninja generator, which only occurs when building in the source tree, so this test cannot be done outside of the source tree. Developer's expectation is, however, that an out-of-source build does not change the source tree. Having "git status" showing differences after running the tests is irritating. This patch removes the in-source build files after executing the test. Change-Id: Ia9fd368c9d54b97a415b63254b45e17bc95ecf45 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add support for -binary option for generated resourcesAlexey Edelev2020-11-121-0/+3
| | | | | | | | | | | | | | | | | Add handling of -binary flag in qt6_add_resources for generated resource file variant. If -binary argument is provided in OPTIONS section of qt6_add_resources function, it will be passed to rcc as argument. File path to output .rcc could be additionally specified by DESTINATION argument. Extra target generated_<resource_filename> will be added to project's 'all' set. Implement tests for new functionality. Fixes: QTBUG-87644 Change-Id: Id1313da499d86f82859d1757c3cfae2d84e894d4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix cmake tests for no-widgets and no-gui configurationsAlexandru Croitor2020-11-101-6/+30
| | | | | | Task-number: QTBUG-86053 Change-Id: I108977546304f203f6e2b7e983bb909b76626a9f Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Clean up the public API a bitAlexandru Croitor2020-10-011-29/+29
| | | | | | | | | | Add some missing versionless functions. Rename some functions that are not meant to be public API, and their usages. Task-number: QTBUG-86827 Change-Id: Ifb66c04cd7598d83fe80c01a92ab2d269ebaf396 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix configuration of CMake tests in-build-treeAlexandru Croitor2020-07-201-0/+5
| | | | | | | | | | | | 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: Get tests/auto/cmake tests workingAlexandru Croitor2020-07-171-26/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The tests/auto/cmake project can be configured separately as a standalone project with qt-cmake, or as part of the overall qtbase standalone tests. To do that a bunch of things were done - Ported all Qt5 strings to Qt6 - Replaced in all projects the use of add_definitions and include_directories with a target based approach, except for 2 tests where we check that the old-style approach works, otherwise the tests would file - Removed some (possibly unneeded) EGL / OpenGL tests - Fixed some C++ code - Added setup code to tests/auto/cmake/CMakeLists.txt to figure out which modules are available and should be tested - Fixed Qt6CTestMacros.cmake to be loaded by Qt6Core - Removed the CMake tests to not be run in qmake builds of Qt because they would fail anyway - Enabled the CMake tests to be part of standalone tests - Disabled auto-passing of the C and CXX compiler cache vars when cross-compiling so that the tests can somewhat pass on boot2qt. This is the issue we encountered in e2b2cd9397c76e91ac1ebe493bcac7696767c02e - Ultimately disabled tests for boot2qt, because the -rpath-link flag is not generated by CMake for some reason. - Added code to setup the environment when running an executable that was built as part of the test, so that the proper Qt libraries are found. This handles both the standalone tests case and separate project case. The remaining unported tests are test_import_plugins which requires quite a bit of work to get some modules and plugins built that were done as part of the qmake .pro files, test_plugins that checks some Network plugins which I'm not sure about, and test_add_big_resource which doesn't work with namespaced builds and there's no good way of detecting those at the moment either. Change-Id: Ic8809c72817d1db81af6c6014c11df6473ad8c75 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Remove the openglextensions moduleEirik Aavitsland2020-06-101-1/+0
| | | | | | | | | | | | | [ChangeLog][General] The QtOpenglExtensions module has been discontinued. It provided only convenience functionality for certain direct OpenGL usage. With the new RHI graphics API abstraction, that is no longer a primary use case. Applications that still need to access that API have a number of alternative options, including QOpenGLExtraFunctions. Fixes: QTBUG-84085 Change-Id: I272af61c69ebcec207b576d67d08b59623d485ec Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>