summaryrefslogtreecommitdiffstats
path: root/cmake/QtBuildInternals
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Make QT_CMAKE_EXPORT_NAMESPACE available in the top-level scopeAlexandru Croitor2025-06-062-12/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously QT_CMAKE_EXPORT_NAMESPACE was set by calling find_package(QtBuildInternals) at repo dir scope, even in a top-level build. Starting with ddcafa0a51c65d86f6b5481f06fce5faeb75920d in qtdeclarative, we now have a deferred call of _qt_internal_write_deferred_qmlls_build_ini_file in the CMAKE_BINARY_DIR scope, which lacks the QT_CMAKE_EXPORT_NAMESPACE variable. This caused errors in a top-level standalone tests build: Error evaluating generator expression $ No target "::qtpaths" CMakeLists.txt:DEFERRED To avoid the error we now set QT_CMAKE_EXPORT_NAMESPACE in the top level scope. To avoid duplicating the code into the QtBaseTopLevelHelpers, we extract the qt_internal_top_level_setup_cmake_and_export_namespace function into a new QtBuildInternalsHelpers.cmake file, which is included by both QtBaseTopLevelHelpers.cmake and QtBuildInternalsConfig.cmake. We also copy and install that file. This has less side effects than trying to call find_package(QtBuildInternals) in the top-level scope. Pick-to: 6.10 Change-Id: I8e54e21d3f07ee86860cad49d6e43e0fdefbcee3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't unconditionally enable the ASM languageJoerg Bornemann2025-05-021-1/+1
| | | | | | | | | | | | | CMake MR #10626 doesn't consider the MSVC compiler as valid assembler anymore, thus unconditionally requiring ASM breaks with CMake > 4.0.1 on MSVC. Enable ASM only on non-Android Unix. Remove the ASM language where it's not needed. Pick-to: 6.5 6.8 6.9 Change-Id: I5df71edfce0f4920e39262f722e4bf95a735f31b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix building tests with qt-cmake-standalone-testJoerg Bornemann2025-02-281-0/+3
| | | | | | | | | | | | | We now require user projects to use find_package(Qt6FooPrivate) if the Qt6::FooPrivate target is used. We don't require this for Qt's autotests. But configuring such a test with qt-cmake-standalone-test failed. Fix this by setting QT_FIND_PRIVATE_MODULES to ON in the CMake project template for standalone tests. Change-Id: I778cbfc16638a94b5fe538c175394501df106b82 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Fix configuring standalone tests with a cross-compiled QtAlexandru Croitor2024-08-021-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | The Qt6 package needs to be found before calling qt_build_internals_set_up_private_api, otherwise it will fail when using a cross-compiled Qt, because QT_HOST_PATH will not be set. The error is: CMake Error at qtbase/cmake/QtBuildHelpers.cmake:341 (message): You need to set QT_HOST_PATH to cross compile Qt. Call Stack (most recent call first): cmake/QtBuildHelpers.cmake:444 (qt_internal_check_host_path_set_for_cross_compiling) cmake/QtBuild.cmake:4 (qt_internal_setup_build_and_global_variables) cmake/QtSetup.cmake:6 (include) cmake/QtBuildRepoHelpers.cmake:21 (include) lib/cmake/Qt6BuildInternals/QtStandaloneTestTemplateProject/Main.cmake:7 (qt_build_internals_set_up_private_api) cmake/QtBuildRepoHelpers.cmake:1036 (include) cmake/QtBuildRepoHelpers.cmake:1053 (qt_internal_setup_standalone_test_when_called_as_a_find_package_component) lib/cmake/Qt6BuildInternals/Qt6BuildInternalsConfig.cmake:68 (qt_internal_setup_build_internals) CMakeLists.txt:11 (find_package) Pick-to: 6.5 6.7 6.8 Fixes: QTBUG-127668 Change-Id: I2fb3df05ce7aed3949d428d98657fe61de723abd Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Allow building all examples as standalone just like testsAlexandru Croitor2024-03-141-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new libexec/qt-internal-configure-examples script that allows to configure and build "standalone examples" just like "standalone tests". This is a prerequisite for using deployment api in examples for prefix builds, otherwise deployment api gets confused not finding various information that it expects from an installed qt. Because the various conditions in the build system for standalone examples are similar to standalone tests, introduce a new QT_BUILD_STANDALONE_PARTS variable and use that in the conditions. The variable should not be set by the user, and is instead set by the build system whenever QT_BUILD_STANDALONE_TESTS/EXAMPLES is set. Unfortunately due to no common file being available before the first project() call, in qtbase builds, per-repo builds and top-level builds, we need to duplicate the code for setting QT_BUILD_STANDALONE_PARTS for all three cases. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: Ia40d03a0e8f5142abe5c7cd4ff3000df4a5f7a8a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Mostly unify includes into a single locationAlexandru Croitor2023-11-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the QtBuildRepoHelpers and QtBuildRepoExamplesHelpers files that were previously loaded as part of BuildInternals package instead be loaded when qt_internal_include_all_helpers is called. Load all the helpers as soon as find_package(QtBuildInternals) is called rather than when qt_build_repo() is called. This is a behavior change, but because including the Qt's Helpers should have no side-effects aside from defining functions, it should be fine. This lets us have a unified location where to include Helpers files, instead of thinking whether it needs to be done in QtBuildInternals or in QtBuildHelpers or some other place. Move also some additional inclusions into the same function. Note that including some upstream CMake files like CMakeFindBinUtils does have side-effects, but we've been doing it already anyway, so moving it to the top should not make a difference because any modifications we would do to the globally assigned variables would have come later when we actually called our own functions. Task-number: QTBUG-86035 Change-Id: I33f36f7e8db69d504c34a4d4a094b98f6fa50ee4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Move qt_internal_read_repo_dependencies into QtBuildRepoHelpersAlexandru Croitor2023-11-271-41/+0
| | | | | | | | | | | | | | | | | | | | Previously qt_internal_read_repo_dependencies had to be defined before QtBuildInternalsExtra.cmake was included because the file called the function. Instead of calling the function in QtBuildInternalsExtra.cmake, just call it later after the Helpers have been loaded. We can do this because the function is always called unconditionally, so no point in doing it in the generated file. This lets us move the function into the QtBuildRepoHelpers. Amends 98e8180e56322ce065e39cc1ef1d65b54caa8c25 Amends a804ac3d881fb036619f323f64e778a9e00b181d Task-number: QTBUG-86035 Change-Id: Idffed8f2eb9d728c779b77b31eba0d24d85752ea Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Split and refactor QtBuildInternalsConfig.cmakeAlexandru Croitor2023-11-271-1469/+20
| | | | | | | | | | Move most of the code into two new files: - QtBuildRepoHelpers.cmake - QtBuildRepoExamplesHelpers.cmake Task-number: QTBUG-86035 Change-Id: I48c4e7c64f0ffb600118172b8e69b26018f36ffb Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Use the standalone test directory name as the project nameAlexey Edelev2023-11-171-5/+9
| | | | | | | | | Using this trick we force CMake xcode generator to give the more specific project name when configuring standalone tests. Change-Id: Ic679003c574c0407bdc8df9eecf3762db214fd50 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Make sure we initialize moc rcc and uic for manual test targetsAlexey Edelev2023-11-161-42/+14
| | | | | | | | | | | | If manual test target is created using the standard Qt API but not qt_internal_add_manual_test command, we need initialize autotools for these targets. Add the generic functionality that ensures that autotools are inialized for all manual tests. Pick-to: 6.5 6.6 Change-Id: Ic048760390174d1be2f01096d70e84458f1c870f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix the dependency list naming when collecting repo dependenciesAlexey Edelev2023-10-241-0/+3
| | | | | | | | | | | | The 'dependencies.yaml' file contains entries that aligned with the repository naming but not the Qt projects naming. When parsing it to collect the dependencies for the standalone repo we should cut the 'tqtc-' repo prefix to avoid malformed names in QT_REPO_DEPENDENCIES variable. Pick-to: 6.5 6.6 Change-Id: If80e61394f245f09b620a9210246053d4e475f86 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix reconfiguration when -no-opengl is specifiedAlexandru Croitor2023-09-131-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In a previous change, we ensured that all INPUT_foo cache variables are unset at the end of configuration, so they don't influence feature re-evaluation in case if a command line flag like -no-gui is not specified upon second reconfiguration and a FEATURE_foo is manually toggled in the CMakeCache.txt, effectively getting rid of stale INPUT_foo values. Unfortunately that causes an issue when configuring with -no-opengl and then trying to reconfigure with 'cmake .' Specifically various feature options like ENABLE / DISABLE use INPUT_foo variables in their expressions. qt_configure_add_report_entry CONDITIONs also use them. These expect the INPUT_foo variables to be persisted, and if they are removed, the expressions might be re-evaluated to a different value, and cause re-configuration to fail or unexpectedly toggle features. To support both cases described above, instead of removing all INPUT variables when configuration ends, only unset those INPUT variables whose corresponding FEATURE_foo variable has been manually toggled in CMakeCache.txt or via an IDE. Toggling a FEATURE_foo manually is intentional, which means the INPUT_foo value should be discarded. Whereas pre-existing INPUT_bar variables will persist, thus not breaking cases like the -no-opengl report CONDITION. Amends 2799391703e44a34b6557e234462e425a61785f2 Pick-to: 6.6 Fixes: QTBUG-116973 Task-number: QTBUG-112957 Change-Id: I5851255bfa41a9a1d116630a5d9f7b9a74aa93ed Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Handle INPUT_foo values when detecting dirty buildsAlexandru Croitor2023-09-061-10/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, the dirty feature code only checked for differences between FEATURE_foo and QT_FEATURE_foo, without taking into account modified INPUT_foo values that might passed via the configure script. This led to issues in certain scenarios when reconfiguring with the configure script. For example configuring with -gui / -DINPUT_gui=ON and then with -no-gui / -DINPUT_gui=OFF would fail saying 'Feature "widgets": Forcing to "ON" breaks its condition' This happens because the widgets feature depends on gui being available, but because INPUT_gui modifications don't trigger the dirty feature re-eval code, we don't recompute the value of widgets. Extract the code that takes into account the INPUT_foo variables into a separate function, and use it both when computing feature values and also when detecting dirty features. This means any non-matching INPUT_foo variables will now also trigger dirty feature checking. Use the same function to replace the duplicate code we have to early initialize the developer-build, no-prefix and pkg-config features. Pick-to: 6.6 Task-number: QTBUG-112957 Change-Id: I775cf70b48291a659b0fecf7cb9570ec12735bca Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Rework INPUT_foo vars handling when reconfiguringAlexandru Croitor2023-09-061-3/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To be able to reconfigure Qt with modified feature values using the configure script, and take into account INPUT_foo values, we need to ignore FEATURE_foo values. But we can't always ignore FEATURE_foo values, because users might want to toggle them by editing CMakeCache.txt or using an IDE. What we can do is tell CMake we are configuring via the configure script, in which case we can mostly be sure that any passed INPUT_foo values should have higher priority than pre-cached FEATURE_foo values. We also need to remove all the cached INPUT_foo variables after they have been used for feature computation, so that subsequent reconfigurations where an INPUT_foo is not passed anymore, doesn't cause a feature to accidentally reuse the previous (stale) value. Pass -DQT_INTERNAL_CALLED_FROM_CONFIGURE=TRUE to CMake when configuring via the configure script, and use that as a marker to make INPUT_foo values have a higher priority. This needs to be done centrally in qt_evaluate_feature and also in a few more locations where we check INPUT_ values, like the developer build and pkgconfig features. Because QT_INTERNAL_CALLED_FROM_CONFIGURE would become a cached variable, we want to remove it at the end of the configuration phase, so that future 'cmake .' reconfigurations are not considered to be done via configure. To do that, we unset it right at the end of qt_build_repo_end in a per-repo build, and in the final qt_print_build_instructions call in a top-level build. The latter needs a cleaner fix in follow up commits in qt5.git and qtbase. Pick-to: 6.6 Task-number: QTBUG-112957 Change-Id: I3fd338092041ef09e3f5a4dfbaf61da5deea0514 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Make sure that tests use the module build directory but not install pathAlexey Edelev2023-09-011-0/+1
| | | | | | | | | | | | | | | | | | | If we configure module that is already installed it's expected that tests use the build directory to resolve all the depdencies, but not the install directory. This is especially sensetive if the module cmake scripts were changed. This changes the order of find_<package|dependency> PATHS that are used to locate Qt package. QT_EXAMPLES_CMAKE_PREFIX_PATH now is used at first, so we guarantee that we look into the build directory at first place. This trick only works if build directory is added to CMAKE_FIND_ROOT_PATH. The reason for that is the internal CMake logic that tries to relocate the search PATHs and put the paths that are subdirs of or exact CMAKE_FIND_ROOT_PATH higher in search list. Fixes: QTBUG-115730 Change-Id: Icab721f0a6eac7301c626350ab214cc4545b368b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix early exit in qt_build_repo_post_process()Joerg Bornemann2023-08-241-6/+5
| | | | | | | | | | | | | This is a macro. We cannot use return() here or we're skipping code at the call site. This commit amends b6849849392cf14ead014833976d1926504985d2. Task-number: QTBUG-88264 Change-Id: Icf6dd06338584239873bf4d66a4bbceef9071399 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
* CMake: Rename QT_EXAMPLES_CMAKE_PREFIX_PATHJoerg Bornemann2023-08-231-5/+5
| | | | | | | | ...to QT_BUILD_CMAKE_PREFIX_PATH, because the variable is now used for examples and tests. Change-Id: Ie6d32a0c99f46407f2771e12638456078c59fb18 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Allow find_package(Qt6 COMPONENTS Foo) in testsJoerg Bornemann2023-08-231-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | In prefix builds of non-qtbase repositories, calls to find_package(Qt6 COMPONENT Foo) did not work in tests, because the find_package calls in Qt6Config.cmake use NO_DEFAULT_PATH, and thus CMAKE_PREFIX_PATH is ignored. Non-external-project examples had the same problem. This was fixed by ffe088941378e32ea30c142cca7e63c537a41ff1 which introduced the variable QT_EXAMPLES_CMAKE_PREFIX_PATH as additional parameter in all relevant find_package calls. We now set this variable in qt_build_tests where it should be local to the tests directory and its children. We cannot use QT_ADDITIONAL_PACKAGES_PREFIX_PATH, because it's value is read once and cached in Qt6Config.cmake - we would have to clear the internal cache variable. It would probably be good to rename QT_EXAMPLES_CMAKE_PREFIX_PATH to reflect that it's not just used for examples. However, my naming skills are drained for today. Task-number: QTBUG-88264 Change-Id: I8bcfe9b7f2ee1f1b75dc725977924d09cb36822c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Fix find_package(Qt6*Tools) in non-qtbase testsJoerg Bornemann2023-08-231-2/+16
| | | | | | | | | | | | | | | | | | | Tests in non-qtbase modules could not find_package their own Qt6*Tools packages, because add_subdirectory(tests) was called before the config files for Qt6*Tools were created. The creation of tools config files is done in QtPostProcess.cmake, which was included in qt_build_repo_end(). Move that include into its own macro, qt_build_repo_post_process() and remove it from qt_build_repo_end(). Call qt_build_repo_post_process() before the 'tests' directory is added in qt_build_repo(). Every call site of qt_build_repo_end() must now be adjusted and call qt_build_repo_post_process(). Task-number: QTBUG-88264 Change-Id: I80d60a1b5c0e9b715c298ef4934b562f815432d1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't create superfluous qtrepo_XXX_for_examples targetsJoerg Bornemann2023-08-211-13/+15
| | | | | | | | | Only create a qtrepo_src_for_examples target that examples, built as external projects, can depend on. Change-Id: I334bc67b9b78f49d5c345cb256132f42dc2c5f5e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Fix running CMake test projects in prefix buildsJoerg Bornemann2023-08-191-33/+7
| | | | | | | | | | | | | | | | | | | | | Consider the following situation: There are CMake tests in qttools/tests/auto/cmake that configure and build CMake test projects, essentially as external projects. One of those test projects does find_package(Qt6 COMPONENTS LinguistTools). This call fails in a prefix build, because Qt6LinguistToolsConfig.cmake is not installed yet. It merely exists in qttools-build/lib/cmake/Qt6LinguistTools. We must adjust CMAKE_PREFIX_PATH to be able to find Qt6LinguistTools. We also must adjust QT_ADDITIONAL_PACKAGES_PREFIX_PATH to be able to find the LinguistTools component of the Qt6 package. Use the prefixes setup from the support for building examples as external projects and use it for CMake test projects as well. Task-number: QTBUG-84884 Change-Id: I1bd5d5084cf931196bdb014cd75ca7578cd9decb Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Allow installation of example sources into the Qt prefixAlexandru Croitor2023-08-161-52/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Qt 5 times, if Qt was configured with -make examples, running make install would not only build and install the example binaries, but would also install the example sources into the prefix. Installation of example sources was not implemented when the Qt 6 build system has switched to using CMake. There is still a use case for it though, mainly for Qt Creator, which only shows the examples of a Qt kit if the sources are available. In contrast to Qt 5, in Qt 6 we will not install example sources by default. It will be opt in. To enable installation of examples sources, configure with configure -make examples -install-examples-sources or cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON The -make examples part is required, otherwise -install-examples-sources has no effect. All example sources can be installed by calling cmake --install . --component examples_sources in the qt repo build directory. In a top-level build, per-repo installation can be done using cmake --install . --component examples_sources_<repo_name> where repo_name could be 'qtbase'. A single example's source can be installed by calling cmake --install . --component examples_sources_<subdir_name> where subdir_name is the subdirectory name of the example, e.g. 'gallery'. Implement installation of example sources by hooking into the qt_internal_add_example command. This means that all examples in all repos need to be added via qt_internal_add_example instead of add_subdirectory, to ensure the sources are installed. The majority of repos already use it. For testing purposes one can configure with -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON -DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation of examples sources without building them. Take into account an additional variable called QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of example sources into a location different from the example binaries. As a cleanup, the NAME option that could previously be passed to qt_internal_add_example_external_project has been removed. That's because it's never used anywhere and could not have worked anyway because qt_internal_add_example_in_tree never handled it. Pick-to: 6.6 Fixes: QTBUG-112135 Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Don't set QT_BUILDING_QT for single standalone testsAlexandru Croitor2023-07-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Standalone test projects have the following condition in the beginning of their project: if(NOT QT_BUILD_STANDALONE_TESTS AND NOT QT_BUILDING_QT) find_package(Qt6BuildInternals COMPONENT STANDALONE_TEST) endif() When configuring the project the first time, QT_BUILDING_QT is not set, find_package is called, configuration succeeds. But because standalone projects implicitly include QtSetup.cmake, that file sets the QT_BUILDING_QT cache var to true, and upon test reconfiguration, cmake errors out with: Unknown CMake command "qt_internal_add_test" or similar. This happens because QT_BUILDING_QT is true on the second reconfiguration and the find_package mentioned above is not executed anymore, leading to unknown internal command errors. Set a new QT_INTERNAL_IS_STANDALONE_TEST variable when we detect a standalone test and check for its value in QtSetup so we don't set QT_BUILDING_QT to TRUE anymore. Adjust a few code locations where QT_BUILDING_QT being false might trigger different behavior for standalone tests. Task-number: QTBUG-93020 Change-Id: I5413b9f37653225175a1006f7626e023045b5979 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
* CMake: Don't use check_language for Objective-C/C++Alexandru Croitor2023-06-291-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The check_language macro spawns a new cmake subprocess to detect availability of a language. We use that to detect availability of the Objective-C/C++ languages when targeting Apple platforms. That's problematic because the parent process CFLAGS / LDFLAGS env vars influences the result of the subprocess compiler detection, and in some cases that can fail the detection. An example of that is passing iOS specific flags which then get mixed with the default macOS flags added by CMake, resulting in a linker failure. Instead of using check_language, explicitly enable the Objective-C and C++ languages when targeting Apple platforms because we know that we need them for compiling Qt. This avoids the issue because enable_language is not spawning a separate cmake sub-process and thus passes more information to the underlying try_compile project to ensure a successful check. The change also means that CMake will error out earlier in case if the Objective-C compiler is not found, which was not the case before. Pick-to: 6.5 6.6 Fixes: QTBUG-114470 Change-Id: I1a16c1e5828dfe10b2d7da27cc9a8c787517ab8e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Fix external header support in qtsyncAlexey Edelev2023-06-091-0/+6
| | | | | | | | | | | We should sync external headers for 3rdpary projects like freetype and harfbuzz-ng and keep the directory structure. Fixes: QTBUG-113416 Pick-to: 6.6 6.5 Change-Id: Ie66edb9a21cff37ca6c8c68b6d225de6d8bbad81 Reviewed-by: Michal Klocek <michal.klocek@qt.io>
* Move QT_ALLOW_SYMLINK_IN_PATHS warning to config.summaryAmir Masoud Abdol2023-06-081-6/+0
| | | | | | | | | | | I think this needs to be more prominent, as I noticed during the testing that it could cause issues if it gets lost in between the config messages, as we knew of course. Pick-to: 6.5 6.6 Task-number: QTBUG-113463 Change-Id: I2ece498a8d3604362a49cc10499b92b0d2764fb9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Implement qt_internal_get_file_path_mode for changing the file path modeAmir Masoud Abdol2023-05-311-0/+16
| | | | | | | | | | | | | In cases where we allow symlink, we need to use ABSOLUTE path, and don't resolve the symlink. This function returns ABSOLUTE only if we are on Apple platform, and have QT_ALLOW_SYMLINK_IN_PATHS enabled. While this is mainly to resolve the issue report by Homebrew, it might be useful if a user really want to build with symlink. Pick-to: 6.5 Task-number: QTBUG-113463 Change-Id: Ided141ed8de66cc1d3717ec2719eb703fa7fc589 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Add the list of previously searched packages to qt_find_packageAlexey Edelev2023-05-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | When configuring Qt the second time it might be situation that the set of qt_find_package calls is changed. One of the scenarios is the changing of the submodule list that needs to be built in top-level builds. It's also applicable for Qt features that lead to extra package lookup in the unlocked subdirectories. Current approach collects packages that were found at the previous run and skips search of the packages that are missing. The problem is that it also skips packages even if qt_find_package was not called at previous run. QT_INTERNAL_PREVIOUSLY_SEARCHED_PACKAGES collects all packages that were actually searched at the previous run to make sure that qt_find_package don't skip packages that appeared at second run only. Note: Described scenarios may still have other issues and are not tested well. Fixes: QTBUG-113244 Pick-to: 6.5 Change-Id: Iab36060a28fbaa16a3b3bdba67795955c496b0c3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
* Introduce the qt_internal_project_setup macroAlexey Edelev2023-04-243-2/+12
| | | | | | | | | | | | The macro sets the required CMake variables and policies and should be called right after the find_package(Qt6 COMPONENTS BuildInternals... call to make sure that the subsequent code adopt all the required policies. Pick-to: 6.5 Task-number: QTBUG-112685 Change-Id: I9f93f728ee4d8ae7743db9fffafa26025c76dcf2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add drive letter to source paths when calling qt-internal- scriptsAmir Masoud Abdol2023-04-141-0/+3
| | | | | | | | | | | | | Like qt-configure-module.bat, when building with unity build, CMake needs to know the full path of the source directory to be able to correctly generate its `*_cxx.cxx` files. So far, this seems to only affect Windows' LLVM/MinGW builds. By this patch, I make sure that we pass the full path to CMake. Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: Ida2da127ecba95856b6e0091936c471c2a116936 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Disable Unity Build for ExamplesAmir Masoud Abdol2023-04-061-0/+4
| | | | | | | Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: I20999512e557db618c14e36d62317680bc17c43a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Improve the internal handling of unity buildAmir Masoud Abdol2023-03-141-0/+5
| | | | | | | | | | | | | | | | | | | - Removed the NO_UNITY_BUILD argument from commands that disable it by default. - Add a warning in case NO_UNITY_BUILD or NO_UNITY_BUILD_SOURCES is being used where it is already disabled, e.g., qt_internal_add_test - Exclude all sources of a target from unity build if NO_UNITY_BUILD is set on the target. This sounds a bit harsh, but I have noticed that sometimes the same source file can be included somewhere else, and some unexpected collision may occur. - qt_examples_build_end excludes all its examples from the unity build. - qt_build_test now sets the CMAKE_UNITY_BUILD to OFF before configuring the tests, and restore its value when done. Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: Ia42e7dd5a5bfb151db241deb639325720fd91eec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Relax example dependencies to be per-repoAlexandru Croitor2023-03-061-2/+28
| | | | | | | | | | | | | | | | | | | | | | | | When doing a top-level build with ExternalProject examples, it doesn't make sense to make qtbase examples depend on e.g. qtdeclarative plugins. Instead the qtbase example should only depend on plugins built in qtbase. Create per-repo custom targets that depend on all plugins built within that particular repo. Create an additional per-repo target which depends on all plugins built in that repo, as well as plugins from dependent repos. Use the latter as a dependency for examples built as part of the current repo. Repo dependencies are parsed from dependencies.yaml. Pick-to: 6.5 Fixes: QTBUG-110913 Change-Id: I149860cc549caf53271c9ea296eb7bac2a663715 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Show a message when configuring examplesAlexandru Croitor2023-02-071-0/+1
| | | | | | | | | | | This somewhat indicates the progress of configuring a specific repo and the slower period of time when configuring examples in-tree. Pick-to: 6.5 Change-Id: I643536c4ebc865933730b7af2a1d0c56bbbf2912 Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Work around AUTOUIC Ninja Multi-Config issue with EP examplesAlexandru Croitor2023-01-201-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | AUTOUIC doesn't handle relative paths to .ui files in parent directories when using Ninja Multi-Config. The designer tool in qttools has such a ui file. This leads to the following error when trying to build qttools together with examples as ExternalProjects and Ninja Multi-Config: ninja: error: 'src/designer/src/designer/designer_autogen/ include_Debug/ui_preferencesdialog.h', needed by 'src/designer/src/designer/designer_autogen:Debug', missing and no known rule to make it Until cmake is fixed, we can work around the issue by not adding designer as a dependency when building EP examples, because no example tries to use the app. We can't exclude all apps from example dependencies because some modules use qt_internal_add_app for tools as well, which are called from public CMake API and also examples. An example of this is qtapplicationmanager. Given that we can't exclude all apps, introduce a function to allow skipping single targets when building EP examples. This will allow excluding designer specifically. The examples will now depend on a new ${repo}_src_for_examples target rather than ${repo}_src, which will exclude skipped targets. Task-number: QTBUG-90820 Task-number: QTBUG-96232 Task-number: QTBUG-110369 Change-Id: I2f900253bbf7bac917f2293ef604ab3ea8f298e1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add find package for lttng library so that it gets added to targetAntti Määttä2023-01-131-0/+4
| | | | | | | | | | Add it globally so that each module using tracepoints don't have to add it themselves to each modules configure.cmake. Pick-to: 6.5 Change-Id: Id58cfaff5cd715b2667da2470001d646117f9f28 Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Allow specifying CMakeLists.txt as the argument for qt-cmake-standalone-testAlexey Edelev2023-01-051-0/+9
| | | | | | | | | | | | | | qt-cmake-standalone-test uses add_subdirectory call when evaluating the project. This leads to an error if users try to use path to CMakeLists.txt as an argument, instead of directory when configuring standalone tests with qt-cmake-standalone-test. It makes sense to check if the user-specified path points to CMakeLists.txt and cut the filename part when calling add_subdirectory. Pick-to: 6.5 6.4 6.2 Change-Id: I6b9ac0ca8323eaf11f219eb1e6bed3057120a231 Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Remove the deprecated TYPE option from qt_add_pluginAmir Masoud Abdol2022-12-071-1/+0
| | | | | | | | | | | As far as I can tell nothing uses TYPE anymore. [ChangeLog][QtCore][CMake] The deprecated TYPE option of the qt_add_plugin() has been removed. You can specify the plugin type using the PLUGIN_TYPE option instead. Change-Id: I786fbc772a23ae0037d9a4cf68018e3af5cb061d Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add INTERFACE_LIBRARIES to dependencies of repo targetsAlexey Edelev2022-12-011-1/+1
| | | | | | | | | | | | Building repo targets may be incomplete as we skip adding INTERFACE_LIBRARIES as dependencies. This leads to the missing artifacts belonging to HEADER_MODULES. It seems reasonable and safe to include INTERFACE_LIBRARIES in the list of dependencies of the repo targets. Pick-to: 6.4 6.2 Task-number: QTBUG-108815 Change-Id: I83f44018f42dcf2fb1e3299461e17ef53e79c2e5 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Update -redo option such that it removes CMakeCache.txt and CMakeFiles/Amir Masoud Abdol2022-12-011-0/+4
| | | | | | | | | | | | | | | | | | In the case of re-doing, `configure` and `configure.bat` pass an extra parameter to the `QtProcessConfigureArgs.cmake`. As a result, CMake removes CMakeCache.txt and CMakeFiles/ before the reconfiguration. If the user is using CMake 3.24 or newer, this is achieved by passing the `--fresh` option to CMake call. In older CMake(s), CMakeCache.txt and CMakeFiles/ found in CMAKE_BINARY_DIR will be removed using a file(REMOVE_RECURSIVE call. [ChangeLog] The -redo option now additionally removes existing CMakeCache.txt file, and CMakeFiles/ directory, and recreates them from scratch. Task-number: QTBUG-108287 Change-Id: I11a5c8f9df1247d11eb7097552e6764463583346 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Reconfigure faster by not looking for missing packagesAlexandru Croitor2022-11-291-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of constantly trying to find packages by calling qt_find_package on each reconfiguration, record which packages were found during initial configuration. Then on a second reconfiguration, skip looking for packages that were not found on the initial configuration. This speeds up reconfiguration on certain platforms and repos. Here are some stats for my macOS qtbase build. not skip 3.69s user 4.96s system 98% cpu 8.750 total skip 2.69s user 1.00s system 97% cpu 3.792 total Top-level build with -submodules=qtquick3d not skip 15.03s user 10.58s system 97% cpu 26.334 total skip 13.87s user 5.16s system 96% cpu 19.724 total Note this is a behavior change from how find_package is used in most CMake projects, where if a package was previously missing, the developer can just install the package and reconfigure to pick it up. With this change, they will first have to remove their CMakeCache.txt file and configure from scratch, or remove the QT_INTERNAL_PREVIOUSLY_FOUND_PACKAGES cache variable and reconfigure. For this reason, we enable this behavior by default only in -developer-builds. Builders can also opt in or out by setting the QT_INTERNAL_SAVE_PREVIOUSLY_FOUND_PACKAGES variable to either ON or OFF. Note this behavior does not apply to user projects, or direct find_package calls (as opposed to qt_find_package). Fixes: QTBUG-107251 Change-Id: Iee9c5d120eb09e2a94eebb059a2174ef6b241e03 Reviewed-by: Kai Köhne <kai.koehne@qt.io> Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Fix a mistake in the documentation of qt_internal_read_repo_dependenciesAmir Masoud Abdol2022-11-261-2/+2
| | | | | | | | If I understood the function correctly, then the example was not quite right. Change-Id: I6b6a4845c5ded2a058050dfbecf5db158d32d12a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Use CMAKE_MESSAGE_CONTEXT for Better CMake Output MessagesAmir Masoud Abdol2022-10-251-0/+4
| | | | | | | | | | | | | Each module now identifies its actions during the configuration by a prefix, e.g., `[QtBase]`. In addition, - I have slightly modified some of the `message()` commands to get a more coherent output. - `syncqt.cpp` prints its output as WARNING if any Change-Id: I3922d75a668d94f402068f4121751b7fcb6522b4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Sync CMake Version with `.cmake.conf`Amir Masoud Abdol2022-10-251-1/+1
| | | | | | | | | As stated in `QtBuildInternalsConfig.cmake`, `cmake_minimum_required` versions should be synced with `qtbase/.cmake.conf`, but it wasn't at the moment. Change-Id: I8100370778707d46abe973b681fd4aba182a7513 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Replace the syncqt.pl script with syncqt toolAlexey Edelev2022-09-271-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Change the license of all CMakeLists.txt and *.cmake files to BSDLucie Gérard2022-08-233-3/+3
| | | | | | | 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: Fix examples to build as external projects when cross-compilingAlexandru Croitor2022-08-051-4/+35
| | | | | | | | | | | | | We forwarded the compiler path to the EP but not the flags that might have been set via the CXX environment variable. Make sure to also forward the flags. Pick-to: 6.2 6.3 6.4 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I0fbf9b595f7885014b1f09d158db52e56a3d5243 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix Ninja Multi-Config dependency issues for top-level targetsAlexandru Croitor2022-08-051-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building qtsvg examples as external projects on Windows with Ninja Multi-Config in a prefix build on the CI, the build would fail with an error message like: ninja: error: 'C:/Users/qt/work/qt/qtsvg/lib/Qt6SvgWidgets.lib', needed by 'RelWithDebInfo/svgviewer.exe', missing and no known rule to make it This can be reproduced locally on Windows if one calls 'ninja svgviewer' instead of just 'ninja'. I wasn't able to reproduce it on macOS, although I have seen some peculiarities in the dependencies there as well. External project examples depend on the ${repo_name}_src custom target to ensure all Qt modules are built, so one would expect that dependency to be sufficient. While trying to figure out what's going wrong, I noticed that running 'ninja -t query qtsvg_src:Debug' showed dependencies on Release libraries, which should not happen. The :Release target looked fine though. I'm still not quite sure why the Release libraries are not built on the first ninja run, despite the example having a proper dependency on qtsvg:Release. Running 'ninja svgviewer' a few more times ends up succeeding at one point, because the SvgWidgets Release library does get built in parallel with the failing example, and the next rebuild would succeed. While trying to fix the :Debug target to have proper dependencies, I noticed that we add dependencies to the ${repo_name}_src custom target via the DEPENDS option of add_custom_target(). That is incorrect, that option should only be used for file level dependencies. For target dependencies, add_dependencies should be used. Doing that fixed both the :Debug dependencies as well as the Windows issue, which is good enough for me. Amends 08f46bb40075778e89ba9aed3cef53d990852022 Pick-to: 6.2 6.3 6.4 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I1888681e2e9362d3237acbdacc83222d6a60b48e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix single standalone tests to use same Qt C++ language stdAlexandru Croitor2022-08-032-1/+5
| | | | | | | | | | | | | | | | | When using qt-cmake-standalone-test, we didn't tell CMake to use the same C++ language standard that Qt used when it was configured. We did tell CMake to do that when configuring tests with qt-internal-configure-tests via the qt_build_tests macro. To ensure the proper standard is set, we also need to find_package(Qt6Core), because the std flag is derived from the QT_FEATURE_cxxyz flag which is set by Core. Change-Id: Ia41f2a24983ddab0107a6446743f7b054df8c033 Pick-to: 6.2 6.3 6.4 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Add license headers to cmake filesLucie Gérard2022-08-033-0/+9
| | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-13 15:09:33 +0000