summaryrefslogtreecommitdiffstats
path: root/cmake/QtBaseGlobalTargets.cmake
Commit message (Collapse)AuthorAgeFilesLines
* Move dependency lookup functionality to the common macroAlexey Edelev2021-06-191-0/+1
| | | | | | | | | | Dependency lookup mechanism is the same for modules and plugins. It makes sense to wrap it using macro. Pick-to: 6.2 Change-Id: I73727743b0f5f40b2d94624f65ebfcf85e8dcc59 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove target specific flags from the linker capabilities checkAlexey Edelev2021-06-161-2/+2
| | | | | | | | | | | | | Remove target specific flags from static_link_order. Move the check to the common config.tests folder. Amends 5fb99e3860eb43f4bacacec7f4a4626cb0159b14 Pick-to: 6.2 Task-number: QTBUG-93002 Task-number: QTBUG-94528 Change-Id: I1368075ec6bd1e743b2b89fd93143df38a278ec2 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add public FindPackageHelpersDominik Holland2021-06-141-0/+1
| | | | | | | | | This makes qt_internal_disable_find_package_global_promotion available, which is needed when linking against QtMultimedia in a static build Pick-to: 6.2 Change-Id: I9b8f6d7b74a8693ac471f8a280e893f4da80a44b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add the check for linker capabilities to resolve circular dependenciesAlexey Edelev2021-06-101-0/+7
| | | | | | | | | | | | | | 'ld' only capable to resolve circular dependencies by wrapping the suspected static libraries and objects using --start/end-group arguments. We want to detect if linker is 'ld' at configure time to decide how to link the resource objects if finalizers are not enabled. The qt_config_compile_test function is extended with an extra argument since it's required to pass custom cmake flags to the ld-related test. Pick-to: 6.2 Change-Id: I484fcc99e2886952d8b0232f37e4e6a35d072931 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove CMake compatibility functions for old APIJoerg Bornemann2021-06-041-1/+0
| | | | | | | | | All repositories define QT_NO_INTERNAL_COMPATIBILITY_FUNCTIONS by now, and we can remove QtCompatibilityHelpers.cmake altogether. Change-Id: I4d8104246e96a4514d5651c104607d651d208d95 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Implement propagation of object files to the end-point executableAlexey Edelev2021-05-271-0/+1
| | | | | | | | | | | | | | | | | | | | 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>
* Add support for building and installing repo target setsJoerg Bornemann2021-05-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Introduce the concept of repository target sets, which is a named set of targets within a Qt module repository. In a Qt repository, a repo target set 'qtfoo' can be defined in the top-level project file with qt_internal_define_repo_target_set(qtfoo DEPENDS Bar Baz) The DEPENDS argument specifies Qt components that need to be find_package'd when building the targets that belong to qtfoo. In subdirectory project files, use qt_internal_include_in_repo_target_set(qtfoo) to mark the file as belonging to the repo target set. To build and install a single repo target set, specify QT_BUILD_SINGLE_REPO_TARGET_SET=qtfoo when configuring the Qt repository. Change-Id: Ic9e6213e3225988fd561f315bc857ee44ff17420 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make qt_internal_walk_libs available in public projectsAlexandru Croitor2021-05-111-2/+4
| | | | | | | | | | | | | | | | | | Needed for the upcoming static plugin mechanism, where we have to extract the list of Qt module dependencies of a target and then extract the plugins associated with those modules. To do that we need to recursively collect the dependencies of a given target. Rename the moved functions to contain the __qt_internal prefix. Also rename the existing QtPublicTargetsHelpers.cmake into QtPlatformTargetHelpers.cmake to avoid confusion with the newly introduced QtPublicTargetHelpers.cmake. Task-number: QTBUG-92933 Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Refactor handling of static pluginsAlexandru Croitor2021-05-111-4/+22
| | | | | | | | | | | | | | | | | | | | Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Make qt-internal-configure-tests relocatableAlexandru Croitor2021-04-261-0/+3
| | | | | | | | | It's important for conan CI builds where the correct installation location of Qt should be used when configuring standalone tests. Task-number: QTBUG-93037 Change-Id: I2465a439aea6826dedfb3217d1c909ad639d4ac0 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Generate better Xcode iOS projectsAlexandru Croitor2021-04-191-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an iOS specific plist file like we do for macOS. If the user hasn't specified a bundle identifier or a development team id, do what qmake does and query the Xcode preferences file to pre-populate those if possible. This allows running cmake -GXcode ./foo on a Qt example project and building it with xcodebuild on the command line without having to go through the IDE to set a development team id or modifying the example project to add a product bundle identifier. Note that the change assumes that the development team id has been previously set / configured via Xcode. If no such id is found, then the value will not be set and the user will still have to specify it either in the project file or via the Xcode UI after the project has been generated. Amends 3a2fa3fec5a43d30f1a93a8e89e2973f23ee4ef3 Pick-to: 6.1 Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix building multi-arch universal macOS QtAlexandru Croitor2021-04-011-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the same approach we use for iOS, which is to set multiple CMAKE_OSX_ARCHITECTURES values and let the clang front end deal with lipo-ing the final libraries. For now, Qt can be configured to build universal macOS libraries by passing 2 architectures to CMake, either via: -DCMAKE_OSX_ARCHITECTURES="x86_64;arm64" or -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" Currently we recommend specifying the intel x86_64 arch as the first one, to get an intel slice configuration that is comparable to a non-universal intel build. Specifying the arm64 slice first could pessimize optimizations and reduce the feature set for the intel slice due to the limitation that we run configure tests only once. The first specified architecture is the one used to do all the configure tests. It 'mostly' defines the common feature set of both architecture slices, with the excepion of some special handling for sse2 and neon instructions. In the future we might want to run at least the Qt architecture config test for all specified architectures, so that we can extract all the supported sub-arches and instruction sets in a reliable way. For now, we use the same sse2 hack as for iOS simulator_and_device builds, otherwise QtGui fails to link due to missing qt_memfill32_sse2 and other symbols. The hack is somewhat augmented to ensure that reconfiguration still succeeds (same issue happened with iOS). Previously the sse2 feature condition was broken due to force setting the feature to be ON. Now the condition also checks for a special QT_FORCE_FEATURE_sse2 variable which we set internally. Note that we shouldn't build for arm64e, because the binaries get killed when running on AS with the following message: kernel: exec_mach_imgact: not running binary built against preview arm64e ABI. Aslo, by default, we disable the arm64 slice for qt sql plugins, mostly because the CI provisioned sql libraries that we depend on only contain x86_64 slices, and trying to build the sql plugins for both slices will fail with linker errors. This behavior can be disabled for all targets marked by qt_internal_force_macos_intel_arch, by setting the QT_FORCE_MACOS_ALL_ARCHES CMake option to ON. To disble it per-target one can set QT_FORCE_MACOS_ALL_ARCHES_${target} to ON. Task-number: QTBUG-85447 Change-Id: Iccb5dfcc1a21a8a8292bd3817df0ea46c3445f75 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* wasm: add cmake build supportLorn Potter2021-04-011-0/+1
| | | | | | | | | | | | | | | | A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Enable NEW policies by CMake version with a global defaultCraig Scott2020-12-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a CMake release introduces a new policy that affects most Qt modules, it may be appropriate to make each module aware of that newer CMake version and use the NEW policy without raising the minimum CMake version requirement. To reduce the churn associated with making that change across all Qt modules individually, this change allows it to be updated in a central place (qtbase), but in a way that allows a Qt module to override it in its own .cmake.conf file if required (e.g. to address the issues identified by policy warnings at a later time). The policies are modified at the start of the call to qt_build_repo_begin(). For commands defined by the qtbase module, qtbase needs to be in control of the policy settings at the point where those commands are defined. The above mechanism should not affect the policy settings for these commands, so the various *Config.cmake.in files must not specify policy ranges in a way that a Qt module's .cmake.conf file could influence. Starting with CMake 3.12, policies can be specified as a version range with the cmake_minimum_required() and cmake_policy() commands. All policies introduced in CMake versions up to the upper limit of that range will be set to NEW. The actual version of CMake being used only has to be at least the lower limit of the specified version range. This change uses cmake_minimum_required() rather than cmake_policy() due to the latter not halting further processing upon failure. See the following: https://gitlab.kitware.com/cmake/cmake/-/issues/21557 Task-number: QTBUG-88700 Pick-to: 6.0 Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Build examples with qmake against a CMake built QtAlexandru Croitor2020-12-041-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | We want to remove the Qt .pro files for projects, except examples, because examples are still meant to build with qmake. To not lose coverage on examples built with qmake, add instructions that will build the qtrepo/examples folder with qmake when the CMake configuration has -DQT_BUILD_EXAMPLES=ON. This means that such configurations will build examples both with CMake and qmake. Aside from making sure that our examples will still build with qmake, it will gives us some some coverage that a CMake-built qmake works correctly. Implementation-wise, add new instructions files that can call qmake and make depending on configuration and target type. Pick-to: 6.0 Fixes: QTBUG-85986 Change-Id: Ie8f4cbcda03c94da2aef455e32f48dad41a4bdb0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Rename QtBuildInternalsAndroid.cmake to QtAndroidHelpers.cmakeJoerg Bornemann2020-11-241-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...and include it in QtBuild.cmake. Commit e8d8b1a5e4c added two different code paths to include QtBuildInternalsAndroid.cmake. This was needed, because: In a top-level build, we must not include files that are not yet installed. We have the source tree available, and "${QT_SOURCE_TREE}/cmake" is in CMAKE_MODULE_PATH. We can use the "module syntax" of the include() command. In a per-repository build, when building against an installed qtbase, we must not include files of the source tree, because that's not guaranteed to be available. However, Qt6BuildInternalsConfig.cmake is installed, and we can directly include QtBuildInternalsAndroid.cmake, which is right next to it. We can circumvent this whole issue by moving the Android-related functions out of the Qt6BuildInternals package and including it in QtBuild.cmake. Pick-to: 6.0 Task-number: QTBUG-88718 Change-Id: I5192ba19bb77952505c20d053d7285f798d16ac5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Remove indirection via Startup target for EntryPointTor Arne Vestbø2020-11-121-1/+0
| | | | | | | | | | | | | The EntryPoint interface target now contains all the logic for what flags and optional static libraries to add when the entrypoint is enabled. The target property QT_NO_ENTRYPOINT can be used to disable the entrypoint. Change-Id: I9b14ff729366cd6307789c969ebd4b2ca19de77d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Bump the minimum required CMake version to build Qt to 3.18Alexandru Croitor2020-11-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new function that returns the minimum CMake version required to build Qt. Pass that value to cmake_minimum_required() when building qtbase and its standalone tests. The minimum supported CMake version is read from qtbase/.cmake.conf and its value should be updated when the need arises. It's the main source of truth for all repos. Provide a way to lower the minimum CMake version at configure time by passing a value via QT_FORCE_MIN_CMAKE_VERSION. This is not an officially supported way of building Qt. If the specified version is lower than Qt's supported minimum, show a warning. Nevertheless the option is useful for testing how Qt builds with a different minimum CMake version due to different policies being enabled by default. Issue warnings for CMake versions that are higher than the minimum version but are known to cause issues when building Qt. A counterpart change is needed in qt5 to ensure the minimum CMake version is set at the proper time for top-level builds. Ideally we would use the same 'check the CMake minimum version` code in all our repositories, but that will cause lots of duplication because we can't really find_package() the code and doing something like include(../qtbase/foo.cmake) hardcodes assumptions about repo locations. So for now we don't bump the minimum version in child repo cmake_minimum_required calls (qtsvg, qtdeclarative, etc). Instead we record both the minimum supported version and the computed minimum version (in case a different version was forced) in QtBuildInternalsExtra.cmake. Then we require qtbase's computed min version in qt_build_repo_begin(). This won't set policies as cmake_minimum_required would, but at least it propagates what minimum CMake version should be used for child repos. We might still have to bump the versions in child repos at some point. Task-number: QTBUG-88086 Change-Id: Ida1c0d5d3e0fbb15d2aee9b68abab7a1648774b9 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix argument passing for configure.bat / qt-configure-module.batJoerg Bornemann2020-10-301-0/+1
| | | | | | | | | | | | | | | | | Passing arguments with equal signs was broken for configure.bat and qt-configure-module.bat. An argument FOO=BAR was split at = and written as FOO BAR to config.opt, breaking every attempt of assigning CMake variables. We must not iterate over %* in batch files to avoid splitting arguments at equal signs. Instead, pass %* unmodified to a CMake script that writes config.opt. Fixes: QTBUG-88019 Change-Id: I7c743a206961d1ed168f2313f864905f6b345b49 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Let doc targets depend on doc tools in top-level buildJoerg Bornemann2020-10-231-0/+1
| | | | | | | | | | | | | | | For top-level builds it's desirable to have "ninja generate_docs" build all tools needed to generate the documentation. This is problematic since the doc-generating targets are created before the doc tool targets. Thus, we must defer the dependency connection if the doc tool target is not yet available. This patch adds the functions qt_internal_defer_dependency and qt_internal_add_deferred_dependencies. Change-Id: Ica940b80882e67cb0e0943e95541f7f4d1885948 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Split QtBaseGlobalTargets.cmake into multiple filesAlexandru Croitor2020-10-121-266/+10
| | | | | | | And wrap the various behaviors into separate functions. Change-Id: If940351af34e445de050f2b46301de7080b1555b Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Workaround iOS Xcode issue when configuring appAlexandru Croitor2020-10-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | It appears that CMake's Xcode generator default behavior can't really handle imported object libraries location, which Qt uses extensively (all the qt_add_resource calls). Specifically the project fails to configure with the following error message: The OBJECT library type may not be used for IMPORTED libraries under Xcode with multiple architectures. An issue was filed upstream at https://gitlab.kitware.com/cmake/cmake/-/issues/21276 In the mean time, it looks like it's possible to work around the issue by setting XCODE_EMIT_EFFECTIVE_PLATFORM_NAME global property to OFF. This needs to be done before the very first project() call, so we do it in the generated Qt toolchain file. Note that the workaround only works if the CMake project is configured with a single architecture given to CMAKE_OSX_ARCHITECTURES. If multiple arches are given, it will fail with the same error message. Fixes: QTBUG-87198 Change-Id: I2556ae28b2fc2d9cfe464a5acf9c4fcbaf01b654 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Introduce Qt6::Startup targetAlexandru Croitor2020-10-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Add an abstraction over Qt::WinMain (aka qtmain.lib) and iOS's runtime linker entry point (_qt_main_wrapper). The Core target will now link against the Startup target on all platforms, instead of just WinMain on Windows. The creation and linkage interface definition of the Startup target is done at find_package(Qt6Core) time via the private call of _qt_internal_setup_startup_target(). This will add automatic linkage of WinMain to executables marked with the WIN32_EXECUTABLE property on Windows. As well as the addition of the '-Wl,-e,_qt_main_wrapper' linker flag when linking iOS executables. Qt users can opt out of this behavior by either setting the QT_NO_LINK_QTMAIN property or variable. This is in line with Qt 5 behavior. Task-number: QTBUG-87060 Change-Id: I7d5e9f1be0e402cf8e67e6f55bfd285f9e6b04f4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: build add flags for building QtAndroid.jarAssam Boudjelthia2020-09-161-0/+1
| | | | | | | | | | | | | Adds -source, -target, -Xlint:unchecked, -bootclasspath flags. Setting default javac build source and target versions to 8. Allow setting custom values for javac build versions via -DQT_ANDROID_JAVAC_SOURCE, and -DQT_ANDROID_JAVAC_TARGET. Task-number: QTBUG-86282 Change-Id: I98f4f193ac96016dc722d178594d7fd401202f68 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Check that QT_HOST_PATH is set when using the Qt toolchainAlexandru Croitor2020-09-151-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a consumer wants to cross-compile a Qt app, they need to provide the host Qt path location. When building Qt in the CI we embed the Qt host path into the generated CMake toolchain file for convenient building of other Qt modules. But once Qt is built, packaged and installed on a user's machine, most likely the Qt host path will not be the same. In such a case, if the user wants to use the convenience toolchain, they should explicitly provide the Qt host path via the QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR variables. Show an error message if the values are not provided or don't exist on the file system. It's possible that in the future the Qt installer will patch the toolchain file, or provide additional info, to point to the host Qt installation so that the user doesn't have to do it manually. But until that's done, a friendly error message is a good way to inform the user what they should do. Task-number: QTBUG-83999 Change-Id: I26291e3c47bb77375f8a5ce7b848c0382a660ca9 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Conditionally set compiler in generated toolchain fileAlexandru Croitor2020-09-151-2/+9
| | | | | | | | | | | | | | | | | | | Public consumers of the qt toolchain file will most likely not have their compilers in the same location where they were on the Qt build machine. Only set the compiler paths if none was set already, and the paths actually exist. This seems to become a trend in the generated toolchain file, and is only a stop-gap solution. A proper solution (two different toolchain files) may follow. Task-number: QTBUG-83999 Change-Id: I7a603af447333a45c65b98e299ee109932d16517 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix incorrect host path used in generated toolchain fileAlexandru Croitor2020-09-151-4/+6
| | | | | | | | | | | | | | | | | | | | | A previous change accidentally broke what we we set for QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR. The QT_HOST_PATH variable should use an absolute path as it was done before. The QT_HOST_PATH_CMAKE_DIR variable incorrectly used the value of "${QT_HOST_PATH}" instead of "${QT_HOST_PATH_CMAKE_DIR}". Fix both of these, and change the names of intermediate variables to be consistent. Amends a6a3b82ffb3d7f1ea13293206401ed360a51e9cd Task-number: QTBUG-85240 Change-Id: I328a7edee12a13ff793684e8a0a4c2e03204eca4 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Introduce qt-configure-moduleJoerg Bornemann2020-09-111-0/+25
| | | | | | | | | | | | | Add a convenience script to configure a Qt module separately. This script reads and interprets the qt_cmdline.cmake files of the Qt module to be configured and eventually calls qt-cmake-private. Example usage: <install-prefix>/bin/qt-configure-module <source-root>/qtdeclarative -qml-network -- --trace-expand --trace-redirect=cmake.trace Change-Id: I026f1a050cd3f4df740611c32ba8c03161bba7a3 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix building of non-qtbase repos on Android with Windows hostAlexandru Croitor2020-09-091-2/+4
| | | | | | | | | | | | | | | | The generated toolchain file embedded windows style paths for the android sdk and chainloaded toolchain. This caused CMake does fail at configure time while trying to evaluate backslashes as escape chars. Also syncqt was searched for in libexec, which is not the right directory on Windows. Use the host info package to get the location of the 'libexec'. Task-number: QTBUG-85399 Task-number: QTBUG-85911 Task-number: QTBUG-86053 Change-Id: I1b15ce84496d52c3fda2f65138e1eac43bc95c9e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Make generated Qt toolchain file a bit more relocatableAlexandru Croitor2020-09-091-3/+15
| | | | | | | | | | | | | | Rather than force setting the apple sysroot and Qt host paths, first check if they are not already defined on the command line and if they aren't, check that the paths with which Qt was configured exist. The goal of the patch is to not set invalid paths, like when using a Qt built in the CI, which will have a different host path / sysroot compared to what a user has locally. Task-number: QTBUG-85240 Change-Id: Ic37566b4fa845d8d1b4e4b5ba7fa4be769e99ca8 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix cmake wrapper creation when cross-buildingAlessandro Portale2020-08-281-3/+3
| | | | | Change-Id: I363ee470973df89d16314671e3c33771040061f2 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Install QtHeadersClean.cmakeFabian Kosmale2020-08-271-0/+1
| | | | | | | | | For prefix builds we need to install the file. Amends db21bad936a761f475145886f1e06dfcfa11eb80. Change-Id: Ia8e859dc048cc4bd74eb95ed0d2adce9c6b11902 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* CMake: Move QtPostProcess functions into QtPostProcessHelpers.cmakeAlexandru Croitor2020-08-141-0/+1
| | | | | | | | | | | The helpers can now be included manually in a project to call any required function. There was a use case for that in qttools, which was not possible because including QtPostProcess early would produce side effects. Task-number: QTBUG-86035 Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Split QtBuild.cmake into smaller filesAlexandru Croitor2020-08-141-14/+43
| | | | | | | | | | | | | | | | | | | | | | | QtBuild.cmake is huge. Split it. Move module, plugin, tools, executables and test related functions out of QtBuild.cmake into separate files. Do the same for many other things too. An additional requirement is that all the new Helpers files only define functions and macros. No global variable definitions are allowed, nor execution of commands with side effects. Some notes: qt_install_qml_files is removed because it's dead code. Some functions still need to be figured out, because they are interspersed and depend on various global state assignments. Task-number: QTBUG-86035 Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Introduce QtFeatureCommon.cmakeJoerg Bornemann2020-08-131-0/+1
| | | | | | | | This file provides common feature-functionality is supposed to be included by QtFeature.cmake and QtProcessConfigureArgs.cmake. Change-Id: Ifb483c2a9c4014d240c2a4d6ff07b5c0ceee9c3a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Properly handle CONFIG += thread aka Threads::ThreadsAlexandru Croitor2020-08-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mkspecs/features/qt.prf adds a dependency on the system threading library if the Qt Core thread feature is enabled. Because qt.prf is loaded by any public or internal Qt project, it's essentially a public dependency for any Qt consumer. To mimic that in CMake, we check if the thread feature is enabled, and and set the Threads::Threads library as a dependency of Qt6::Platform, which is a public target used by all Qt modules and plugins and Qt consumers. We also need to create a Qt6Dependencies.cmake file so we find_package(Threads) every time find_package(Qt6) is called. For the .prl files to be usable, we have to filter out some CMake implementation specific directory separator tokens 'CMAKE_DIRECTORY_ID_SEP' aka '::@', which are added because we call target_link_libraries() with a target created in a different scope (I think). As a result of this change, we shouldn't have to hardcode Threads::Threads in other projects, because it's now a global public dependency. Task-number: QTBUG-85801 Task-number: QTBUG-85877 Change-Id: Ib5d662c43b28e63f7da49d3bd77d0ad751220b31 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix build with custom INSTALL_INCLUDEDIRJoerg Bornemann2020-08-061-5/+5
| | | | | | | | | | | | | The include directory in Qt's build directory is always named "include", no matter what the value of INSTALL_INCLUDEDIR is. The main reason is that the name "include" is hard-coded in syncqt. The INSTALL_INCLUDEDIR variable must only affect the installation location of headers. Fixes: QTBUG-85893 Change-Id: I5367bc589cba129eb41817e2b58d470f730bb5ac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix generated content of prl files (again)Alexandru Croitor2020-07-311-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Apply the same kind of transformations to the contents of the prl files as we do for pri files. Mainly, transform system library paths that are absolute, into link flags to make them relocatable across systems. Also change the Qt frameworks to be linked via the -framework flags instead of via absolute paths. Implementation notes Move the common required functions for both QtFinishPrlFile and QtGenerateLibPri into a common QtGenerateLibHelpers.cmake file. Make sure it's listed as a dependency for the custom commands. Also make sure to pass the necessary input values like possible library prefixes and suffixes, as well as the link flag. Task-number: QTBUG-85240 Task-number: QTBUG-85801 Change-Id: I36f24207f92a1d2ed3ed2d81bb96e4e62d927b6e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Introduce qt_internal_add_appAlexandru Croitor2020-07-311-0/+2
| | | | | | | | | | | | | | | This new function is meant to be used where load(qt_app) is used. It delegates functionality to qt_add_executable, while handling some additional behavior via a finalization function (mostly handling of macOS Info.plist files and icons, as well as Windows icons and resource files) It uses a new PlatformAppInternal interface target. Task-number: QTBUG-85757 Change-Id: I1a2d5851b137fcd4a6323e0e06fb154f91619800 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Fix handling of CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATHAlexandru Croitor2020-07-241-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While trying to implement the 'host artifact reuse' Coin instructions change, a bug surfaced where the qemu configurations didn't find the host tools and instead tried to use the cross-compiled tools while building qtbase, which failed due to not finding the runtime linker (another unsolved issue). Before the host artifact reuse change, the host tools were found successfully. The difference that caused the issue is that the target install prefix was a direct subfolder of the host prefix. host - /home/qt/work/qt/install target - /home/qt/work/qt/install/target Before the host reuse change the install prefixes were as follows host - /home/qt/work/qt/install/host target - /home/qt/work/qt/install/target While looking for the Qt6CoreTools package, we temporarily set CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH to contain first '/home/qt/work/qt/install' and then '/home/qt/work/qt/install/target'. CMake then reroots the CMAKE_PREFIX_PATH values onto values in CMAKE_FIND_ROOT_PATH, making an MxN list of prefixes to search. Rerooting essentially means concatenating 2 paths, unless the considered prefix is a subfolder of the root path. What happened was that the first considered value was '/home/qt/work/qt/install/home/qt/work/qt/install', a non-existent location that gets discarded. The second considered value was '/home/qt/work/qt/install/target. The second value is the result of seeing that '/home/qt/work/qt/install/target' is a subfolder of '/home/qt/work/qt/install' and thus the root path is stripped. All of this is done in cmFindPackageCommand::FindConfig() -> cmFindCommon::RerootPaths. The behavior above caused the target tools be found instead of the host ones. Before the host reuse change, both of the initial constructed prefixes were discared due to them not existing, e.g. '/home/qt/work/qt/install/target/home/qt/work/qt/install/target' and '/home/qt/work/qt/install/host/home/qt/work/qt/install/host' One of the later prefixes combined CMAKE_FIND_ROOT_PATH == '/home/qt/work/qt/install/host' + CMAKE_PREFIX_PATH == '/' resulting in '/home/qt/work/qt/install/host/' and this accidentally found the host tools package. We actually stumbled upon this issue a while ago when implementing Qt 5.14 Android CMake support in 52c799ed4425076df4353c02950ea1444fe5f102 That commit message mentions the fix is to add a "lib/cmake" suffix to the PATHS option of find_package(). This would cause the subfolder => strip root behavior mentioned above. So finally the fix. First, make sure not to append QT_HOST_PATH in the toolchain file, there shouldn't be any need to do that, give that we temporarily set it when looking for Tools packages. Second, recreate the subdir scenario in the Qt toolchain file by setting CMAKE_FIND_ROOT_PATH to the current (relocated) install prefix as usual, but also setting CMAKE_PREFIX_PATH to a new value poining to the CMake directory. Aka '/home/alex/qt' and '/home/alex/qt/lib/cmake'. Third, when a QT_HOST_PATH is given, save 2 paths in the generated Qt toolchain: QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR. There are the host equivalents of the target ones above. Use these values when looking for host tools in Qt6CoreModuleDependencies.cmake, again facilitaing the subdir behavior. Note these are currently absolute paths and are not relocatable. We'll have to figure out if it's even possible to make the host path relocatable. Finally as a cleanup, look for the Qt6HostInfo package in QtSetup strictly in the given QT_HOST_PATH, so CMake doesn't accidentally find a system Qt package. Change-Id: Iefbcfbbcedd35f1c33417ab7e9f44eaf35ff6337 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* Add OS-specific prelude to qt-cmake-standalone-testJonas Karlsson2020-07-151-0/+2
| | | | | | | | | | | | This makes sure the executable is run as a shell script with the proper interpreter on Unix systems. Otherwise it will fail in some shells, like fish. On windows, it prevents all commands in the batch file from displaying on the screen. Change-Id: If554262f172b035b9661b3e2ff26a96789fa707b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix qt-cmake-standalone-test when CMAKE_STAGING_PREFIX is setJoerg Bornemann2020-07-091-3/+3
| | | | | | | | | | The qt-cmake-standalone-test script is kind of a "host tool" and contained paths to CMAKE_INSTALL_PREFIX, which is wrong if CMAKE_STAGING_PREFIX points to somewhere else. Fixes: QTBUG-85336 Change-Id: I4828dc6868d55cfc60f3ad2199185230d5cc9028 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Generate qdevice.pri when cross-buildingJoerg Bornemann2020-06-291-0/+1
| | | | | | | | | | | | | This adds the CMake equivalent to the classical -device-option key=value configure argument: -DQT_QMAKE_DEVICE_OPTIONS=key1=value1[;keyN=valueN] The keys and values get dumped verbatim into qdevice.pri. This patch also ports the machineTuple configure test. Its result is written into qdevice.pri as value for the GCC_MACHINE_DUMP variable. Change-Id: I29f2323fd87639fafaed99ec7446c7ee75504705 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Support cross-compilation with qmakeJoerg Bornemann2020-06-291-0/+1
| | | | | | | | | | | | | When cross-compiling, we now create a target_qt.conf file that's to be used with the host Qt's qmake. With "qmake -qtconf .../target_qt.conf" projects can be cross-built against the cross-built Qt. We also create wrapper scripts for the host qmake to save the user from passing the -qtconf argument. Fixes: QTBUG-82581 Change-Id: Ib5866e7e820369efea9eb3171e3e3e3ca5c0c3c1 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Improve automatic compiler embedding into the Qt toolchainAlexandru Croitor2020-06-181-4/+42
| | | | | | | | | | | | | | | | | Embedding the initial CMAKE_CXX_COMPILER into qt.toolchain.cmake breaks Boot2Qt builds, because the CXX environment variable is not used anymore when building qtsvg or other projects. Disable automatic embedding when cross-compiling, while keeping it enabled for non-cross-compiling cases (to keep Windows and and ICC configurations working). Allow opting in or out of the embedding in case if the default is wrong, via QT_EMBED_TOOLCHAIN_COMPILER. Task-number: QTBUG-85067 Change-Id: I1d8f9f580bc379b77c34eefb5728bb49f93cc81a Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Do not generate qtbase/bin/qt.confJoerg Bornemann2020-06-111-1/+0
| | | | | | | | | | | | | | | | | | In a qmake build this file serves the purpose of setting the right prefixes for the build directory's qmake binary. This can be used to build Qt repositories other than qtbase, esp. in a top-level build. In the CMake build, we don't have qmake top-level builds, and we do not support building Qt repositories with the build directory's qmake binary (exception: non-prefix build). To build a Qt module or user project with qmake, the installed qmake must be used. This fixes qmake for non-prefix top-level CMake builds. Change-Id: Ibd10c36e8359225553d782d0c8117760db9f3370 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix libraries in qt_lib_XXX_private.pri files for NMCJoerg Bornemann2020-06-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | qmake_use.prf understands the _DEBUG and _RELEASE suffixes for QMAKE_LIBS_XXX entries. The CMake configuration "Debug" is considered for the _DEBUG entries, "Release" and "RelWithDebInfo" for _RELEASE. The qt_lib_XXX_private.pri files are now generated in multiple steps: 1. The QT_LIBS_XXX information is generated per $<CONFIG> and written to .cmake files. 2. A preliminary qt_lib_XXX_private.pri file is generated, containing only configuration-independent data. 3. A custom command runs the QtGenerateLibPri.cmake script that combines the files from step 1 and 2 into the final qt_lib_XXX_private.pri file. The same is done for mkspecs/qmodule.pri. To be able to trigger custom commands from header modules, which are interface libraries, we introduce one XXX_timestamp ALL target per header module that creates a timestamp file. To that XXX_timestamp target we add the pri file generation target as dependency. Fixes: QTBUG-84348 Change-Id: I610f279e37feeb7eceb9ef20b3ddfecff8cfbf81 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Do not create Qt6ToolsConfig[Version].cmake filesJoerg Bornemann2020-06-081-19/+0
| | | | | | | | They are not necessary, and they conflict with what qttools generates. Fixes: QTBUG-82133 Change-Id: I4a1273d694626345b32b45c653dd31d3b78621eb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Protect against Qt toolchain file recursive inclusionAlexandru Croitor2020-06-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Three different people have encountered the issue that calling calling qt-cmake on a project prints 1000 inclusion lines of the same qt toolchain file, and then CMake bails out saying can't find the CMAKE_MAKE_PROGRAM Ninja. This happened because people accidentally called qt-cmake to configure qtbase (instead of just cmake), which created a toolchain file that chainloads itself recursively. Error out when configuring qtbase, and when using the generated toolchain file in the case when it would try to include itself. The solution is to remove the qtbase CMakeCache.txt file, and configure qtbase again, so it generates a proper qt.toolchain.cmake file. If somebody feels enthusiastic, they can move the check into the qt-cmake and qt-cmake-private shell scripts, and error out before the qtbase/CMakeCache.txt is polluted with the wrong toolchain file. That is left for people that feel more comfortable with bash and batch scripting. Change-Id: If518c94791fe7c30731e6e462e347f26a5213c64 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix standalone tests to work properly on reconfigurationAlexandru Croitor2020-06-041-0/+8
| | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-08 16:12:14 +0000