summaryrefslogtreecommitdiffstats
path: root/CMakeLists.txt
Commit message (Collapse)AuthorAgeFilesLines
* cmake: add _extra_files IDE target from heuristicsTim Blechmann8 days1-0/+2
| | | | | | | | | | | Lots of files in the repos are not included into the generated IDE projects. Therefore we add utility targets (custom targets), which are populated by glob patterns, which should fit most files that are found in qt's subprojects. Pick-to: 6.7 Change-Id: I1b731e65f8db319d3cec817eea5c23a1eeaefb22 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Move most of CMakeLists.txt into QtBaseHelpers.cmakeAlexandru Croitor2024-03-141-184/+4
| | | | | | Pick-to: 6.7 Change-Id: I19761dbeebdd2529ef0c493a9a61a1c6fe58667b Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* cmake: build repo helpers - fine-grained test/example optionsTim Blechmann2024-02-081-9/+2
| | | | | | | | | | | the tests/examples could only be enabled globally. when working on a specific repo, it's beneficial to disable tests/examples for other projects to reduce project sizes (and cmake configure/generate times) Change-Id: I0026ba87b667d427043cc8eb1baa6c28b2046dd7 Pick-to: 6.7 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix find_package(Qt6*Tools) in non-qtbase testsJoerg Bornemann2023-08-231-7/+9
| | | | | | | | | | | | | | | | | | | 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>
* Consider BUILD_SHARED_LIBS when adding libraries using _qt_internal_add_libraryAlexey Edelev2023-08-041-17/+17
| | | | | | | | | | | | | | | | | It does look safe to consider the value of BUILD_SHARED_LIBS in _qt_internal_add_library. Current behavior might confuse users that specify BUILD_SHARED_LIBS explicitly but get the library types according to Qt build type. [ChangeLog][CMake] qt6_add_library now considers the value of the BUILD_SHARED_LIBS variable. If the variable is DEFINED it has higher priority than the library type detecting logic in qt6_add_library when adding the library targets. Change-Id: I1c40e887c4e481424a596c870a8ff2784b08fcbb Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Introduce QT_ALLOW_SYMLINK_IN_PATHS flagAmir Masoud Abdol2023-05-031-5/+20
| | | | | | | | | | | `QT_ALLOW_SYMLINK_IN_PATHS` disables the `qt_internal_check_if_path_has_symlinks` command. This allows people of Homebrew to get their build working without having to patch the entire function, as they currently do. Pick-to: 6.5 Change-Id: I4fed3ca497684364eaabbdbc44f1e148e3f28bd7 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Introduce the qt_internal_project_setup macroAlexey Edelev2023-04-241-0/+2
| | | | | | | | | | | | 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>
* Rid of 'special case' markersAlexey Edelev2023-04-131-2/+0
| | | | | | | | | | | It's unlikely we will ever use pro2cmake at this project stage, so it doesn't make any sense to keep the 'special case' markers in the CMake scripts. Remove them and replace with TODO where needed. Change-Id: I84290c20679dabbfdec3c5937ce0428fecb3e5a7 Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> 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>
* 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>
* Use REALPATH based check for symbolic links on WindowsAlexey Edelev2022-01-071-14/+28
| | | | | | | | | | | | | | Windows mount points are marked as symbolic links by CMake. So switch back to the REALPATH based check for Windows hosts. Amends dcc2704d17bda08e6dc7783559ccbfd864dd4339 Pick-to: 6.2 6.3 Task-number: QTBUG-99416 Change-Id: Ic996db1fac5c0b5edc18728535240e272dd435e0 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: David Schulz <david.schulz@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Use IS_SYMLINK condition instead of REALPATH when checking BINARY_DIRAlexey Edelev2022-01-041-12/+16
| | | | | | | | | | | | | | For case-insensitive file systems, the REALPATH file component may return file paths in a different case than ABSOULEPATH. We use REALPATH to detect symlinks. In case-sensitive file systems there still might be the situation when /path/to/Build is a symlink to the /path/to/build, so we cannot make the comparison case-insensitive. Use the IS_SYMLINK check instead. Pick-to: 6.2 6.3 Fixes: QTBUG-99416 Change-Id: Idf998b9e09837a834139553fb822e05b2a0a1949 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Include Qt6WasmMacros in WASM buildDavid Skoland2022-01-031-0/+1
| | | | | | | | | This fixes the issue where WASM could not even be configured with autotests enabled. Change-Id: I0890d52754de92fa84be170906fcb0478e90304e Pick-to: 6.3 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Add _make_aab targetAlexey Edelev2021-11-301-1/+1
| | | | | | | | | | | | | | | | Add target triggering AAB creation. Since the _make_aab target is not added to the ALL set, we may avoid dependency check for it and admit that the target is "always out of date". [ChangeLog][Android][Platform Specific Changes] Add the extra _make_aab targets for each executable target, that can be used to generate android app bundles. Also add aab metatarget to build all _make_aab targets that are created in the project. Pick-to: 6.2 Fixes: QTBUG-96710 Change-Id: I3b0c7fbb5a7dd493ca7a124c4e4b91fd857386bd Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Enforce minimum CMake version in user projectsAlexandru Croitor2021-08-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces new behavior to error out when configuring user projects if the CMake version used is too old for Qt to work with. The main motivator is the requirement of new CMake features to ensure object libraries are placed in the proper place on the link line in static builds. The minimum CMake version is computed based on whether Qt was configured as shared or static libraries. At the moment the required versions for building and using Qt are the same. The minimum versions are defined in qtbase/.cmake.conf in the following variables QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_SHARED QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_BUILDING_QT_STATIC QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_SHARED QT_SUPPORTED_MIN_CMAKE_VERSION_FOR_USING_QT_STATIC Qt Packagers can disable the version check when configuring Qt by setting QT_FORCE_MIN_CMAKE_VERSION_FOR_BUILDING_QT and QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT. In this case it is the packagers responsibility to ensure such a Qt works correctly with the specified CMake version. User projects can also set QT_FORCE_MIN_CMAKE_VERSION_FOR_USING_QT to disable the version check. Then it's the project's developer responsibility to ensure such a Qt works correctly. No official support is provided for these cases. Implementation notes. The versions required to build Qt are stored in QtBuildInternalsExtra.cmake whereas the versions required to use Qt are stored in a new QtConfigExtras.cmake. Also the policy range variables stored in QtBuildInternalsExtra.cmake are now regular variables instead of cache variables, to properly allow overrides per-repository. Some renaming of functions and variables was done for a bit more clarity and easier grep-ability. Pick-to: 6.2 Task-number: QTBUG-95018 Change-Id: I4279f2e10b6d3977319237ba21e2f4ed676aa48b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Bump min required CMake version for static Qt builds to 3.20Alexandru Croitor2021-08-041-12/+17
| | | | | | | | | | | | | | | | | | | | | | | Building a static library Qt configuration will now require a minimum CMake version of 3.20. Qt builders and packagers can still opt out of the mentioned minimum required version by configuring Qt with QT_FORCE_MIN_CMAKE_VERSION. Such a Qt configuration is /NOT SUPPORTED/. To facilitate these changes, the minimum version check has been moved to happen after the BUILD_SHARED_LIBS option is computed by either QtAutoDetect.cmake or set by a user provided cmake toolchain file. Introduce a new QT_MIN_SUPPORTED_CMAKE_VERSION_FOR_STATIC_QT variable in .cmake.conf to mark the minimum version for a static Qt build. Pick-to: 6.2 Task-number: QTBUG-95018 Change-Id: Idc1875729f26a7c635b6bd26ac0c1be973917c13 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io>
* CMake: Bump min required CMake version for shared Qt builds to 3.16Alexandru Croitor2021-07-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Building a shared library Qt configuration already required a minimum CMake version of 3.16, because we depend on CMake's Autogen.json files which are used for metatype.json file generation. If a lower version was used, a FATAL_ERROR was issued in qt6_extract_metatypes. This change is essentially moving the check to happen earlier in the qtbase configure process. User projects will now /also/ officially require a minimum of 3.16 (up from 3.14). As a consequence, the min/max version policy range that is set in the public QtFooConfig.cmake files is changed from 3.14..3.19 to 3.16..3.20 The upper bound is raised because building and using Qt works fine with all CMake 3.20 policies set to NEW. [ChangeLog][CMake] Building Qt as shared libraries now requires CMake version 3.16 or later. Building user projects with CMake using that Qt installation also requires a CMake version of 3.16 or later. Pick-to: 6.2 Task-number: QTBUG-95018 Change-Id: I77d2829370f1dfc90b4071bebc8a3ade654e59e6 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Fix global 'apk' target to actually build all apksAlexandru Croitor2021-06-081-1/+4
| | | | | | | | | | | | | | | | | | | | This means calling 'ninja apk' in a user project with multiple android applications will build all their respective apks. For user projects, make the 'apk' target part of the global 'ALL' target, so that a regular 'ninja' call implies the 'apk' target. We don't do it currently for Qt builds, because certain test executable apks fail to build. Add a QT_NO_GLOBAL_APK_TARGET_PART_OF_ALL variable to allow removing the global apk target from the 'all' target. Pick-to: 6.1 Task-number: QTBUG-94264 Change-Id: I171b9da50eb7d670176704bd26dc1c492118b434 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Remove legacy code path from qt_add_resourceJoerg Bornemann2021-06-071-3/+0
| | | | | | | | All repos use the updated version of qt_add_resource, and we can remove the legacy code path. Change-Id: I15ba64a08c3fad9712a5cf05715594b1ee755bfc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove CMake compatibility functions for old APIJoerg Bornemann2021-06-041-3/+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>
* Build examples in isolated sub-builds using ExternalProjectCraig Scott2021-05-261-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Examples are intended to show how to build against an installed Qt. Building them as part of the main build means the way the Qt targets are defined and created are not representative of an end user's build. By building them as separate projects using ExternalProject, we can more closely replicate the intended audience's environment. This should allow us to catch more problems earlier. Having examples built as part of the main build also creates problems with some static builds where a tool built by the main build is needed during configure time. This happens with other repos like qtdeclarative but not (currently) with qtbase. Converting the examples in qtbase to be built using ExternalProject is intended as a demonstrator for how other repos can do similar. Until other repos are converted, they will continue to work as they did before, with examples as part of the main build for non-static builds only. The new build-externally behavior is only supported for non-prefix builds with this change. Prefix builds will continue to use the old non-external method. Support for building examples externally in prefix builds will be a separate change. Task-number: QTBUG-90820 Fixes: QTBUG-91068 Change-Id: I2304329940568dbdb7da18d54d5595ea7d8668bc Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix BASE argument of qt_add_resourcesJoerg Bornemann2021-05-181-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BASE argument of qt_add_resources now denotes the root point of the alias of the file. Before, BASE was merely prepended to every file that got passed to qt_add_resources. Old behavior: qt_add_resources(app "images" PREFIX "/" BASE "../shared" FILES "images/button.png") Alias is "../shared/images/button.png", and pro2cmake generated QT_RESOURCE_ALIAS assignments to fix this. New behavior: qt_add_resources(app "images" PREFIX "/" BASE "../shared" FILES "../shared/images/button.png") The alias is "images/button.png". No extra QT_RESOURCE_ALIAS assignment is needed. The new behavior is in effect for user projects and for Qt repositories that define QT_USE_FIXED_QT_ADD_RESOURCE_BASE. Qt repositories will be ported one by one to this new behavior. Then the old code path can be removed. Pick-to: 6.1 Task-number: QTBUG-86726 Change-Id: Ib895edd4df8e97b54badadd9a1c34408beff131f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Be more helpful about the symlinked build directory problemAndreas Hartmetz2021-05-181-2/+9
| | | | | | | | - Explain why a symlinked build dir won't work - Add another workaround suggestion that works well in my case Change-Id: I3f7eaeac2974e037587941f6f761fbcb262c4631 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: add an option to enable or disable versioned hard linkLi Xinwei2021-05-131-0/+3
| | | | | | | | | | | The option is called QT_CREATE_VERSIONED_HARD_LINK. By default, it is set to ON. Users can set this option to OFF to disable versioned hard link. Pick-to: 6.1 Fixes: QTBUG-93636 Change-Id: I0ffa1ee1c6bae1950df332fcce3152a861b33db0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Generate better Xcode iOS projectsAlexandru Croitor2021-04-191-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Fix build without features.settingsTasuku Suzuki2021-04-151-1/+1
| | | | | Change-Id: Id13980fd5124afe1ee2d378590eb7a4e11b7a4fb Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
* CMake: Choose better defaults for qt_add_plugin STATIC/SHAREDAlexandru Croitor2021-04-071-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* wasm: add cmake build supportLorn Potter2021-04-011-0/+6
| | | | | | | | | | | | | | | | 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>
* Fix double inclusion of QtAutoDetect.cmake in top-level buildJoerg Bornemann2021-03-041-1/+1
| | | | | | | | | | The variable we need to check is called QT_SUPERBUILD, not QT_SUPER_BUILD. Pick-to: 6.1 6.0 Change-Id: I8487f491a0a4cebdf08f579519e99e6afe3db8c2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Bail out if the build dir is symlinkedJoerg Bornemann2020-12-211-0/+10
| | | | | | | | | | | | | | | | Building Qt in a symlinked build directory leads to all kind of issues, like unnecessary rebuilds, strange compilation errors or already errors at configure time. Detect this situation and bail out early with an informative error message. Task-number: QTBUG-88418 Task-number: QTBUG-89559 Change-Id: I70c16e11a7eede7a183f6f56b73ea93f985312f3 Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Gatis Paeglis <gatis.paeglis@qt.io> Reviewed-by: Liang Qi <liang.qi@qt.io>
* CMake: Enable NEW policies by CMake version with a global defaultCraig Scott2020-12-071-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Name QT_NO_MAKE_*/BUILD_* variables consistentlyJoerg Bornemann2020-11-201-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | For consistency, apply the following renamings: QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT BUILD_EXAMPLES -> QT_BUILD_EXAMPLES BUILD_TESTING -> QT_BUILD_TESTS This should help to better convey the difference between "BUILD" and "NO_MAKE". To configure tests, but not to build them by default, pass the following to CMake: -DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF Analoguous for examples: -DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF Tools can be excluded from the default build with: -DBUILD_TOOLS_BY_DEFAULT=OFF The variable BUILD_TESTING is still available and initialized with the value of QT_BUILD_TESTS. Pick-to: 6.0 6.0.0 Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Do not set PKG_CONFIG_* environment variablesJoerg Bornemann2020-11-121-10/+0
| | | | | | | | | | | | | This reverts commit 9968a211f92c2b4d5bd1fe004f16ec1c5f968dcd. The PKG_CONFIG_* environment variables should be added by the user environment, preferably by the toolchain file. Apparently, the change was added for Android before we turned off pkg-config for Android. It is not needed anymore. Change-Id: Ieeed09ae53a606c85d4937f463286b5b0f76bde9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Bump the minimum required CMake version to build Qt to 3.18Alexandru Croitor2020-11-031-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 building examples targeting iOS simulator with qmakeAlexandru Croitor2020-10-161-1/+2
| | | | | | | | | | | | | | | | | | | The makefile generated by qmake when building an iOS example tries to execute the mkspecs/features/uikit/devices.py python script to find a simulator ID. When installing the mkspecs, we didn't preserve the source file permissions which means that the executable bit was stripped. This causes the makefile to call xcodebuild with an invalid simulator id due to not being able to execute the python script. Make sure to install the mkspecs directories preserving the source file permissions. Fixes: QTBUG-87639 Change-Id: Iaa33b740c93187155025891104e8a21c6e7c98c8 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Do not run auto-detection in top-level buildsJoerg Bornemann2020-10-121-3/+4
| | | | | | | | | | | The top-level CMakeLists.txt already does that to ensure that QtAutoDetect is included before any project command, meaning before any toolchain file is loaded. Task-number: QTBUG-87309 Change-Id: I60a998bdf999b6f751e4ebec2d13491fb206b132 Reviewed-by: Cristian Adam <cristian.adam@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Refactor optimization flag handling and add optimize_fullAlexandru Croitor2020-10-061-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a bunch of helper functions to manipulate compiler flags and linker flags for the CMAKE_<LANG>_FLAGS_<CONFIG> and CMAKE_<LINK_TYPE>_LINKER_FLAGS_<CONFIG> CMake variables. These variables can be assigned and modified either in the cache or for a specific subdirectory scope, which will apply the flags only to targets in that scope. Add qt_internal_add_optimize_full_flags() function which mimics qmake's CONFIG += optimize_full behavior. Calling it will force usage of the '-O3' optimization flag on supported platforms (falling back '-O2' where not supported). Use the function for the Core and Gui subdirectories, to enable full optimization for the respective Qt modules as it is done in the qmake projects. To ensure that the global qmake-like compiler flags are assigned eveywhere, qt_internal_set_up_config_optimizations_like_in_qmake() needs to be called after Qt global features like optimize_size and optimize_full are available. This means that qtbase and its standalone tests need some special handling in regards to when to call that function. Task-number: QTBUG-86866 Change-Id: Ic7ac23de0265561cb06a0ba55089b6c0d3347441 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Disable usage of CMake API compatibility wrappersAlexandru Croitor2020-09-231-0/+3
| | | | | | | | | Setting the QT_NO_INTERNAL_COMPATIBILITY_FUNCTIONS variable in the project ensures we ported away from old API calls. Task-number: QTBUG-86815 Change-Id: I0d1868a24b0f4e0cc817c11fef160f8b392814af Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix tst_moc to build when tests are built as part of Qt treeAlexandru Croitor2020-08-231-0/+1
| | | | | | | | | | | | | tst_moc uses qt_wrap_cpp, which tries to dispatch to qt6_wrap_cpp depending on the value of QT_DEFAULT_MAJOR_VERSION. That value is only set in Qt6CoreConfigExtras.cmake.in, which is not loaded as part of the qtbase build unless something does find_package(Qt6Core). Set the QT_DEFAULT_MAJOR_VERSION to 6 before including the Qt6CoreMacros in the qtbase top-level project. Change-Id: I7b81d89d965f755e51727007e68771ac3931ac55 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Implement configure -optimize-debugJoerg Bornemann2020-08-201-0/+3
| | | | | | Task-number: QTBUG-85373 Change-Id: I3aba1fcf96e36544dd75a5e6adc5f770a9a45726 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Split out some Android functions into a public API fileAlexandru Croitor2020-08-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To fix CMake Qt For Android projects to configure, we need to move some functions from a private CMake API file only, to a public one. Add Qt6AndroidMacros.cmake which will be loaded by Qt6Core package. We'll have to decide how we proceed with Qt5AndroidSupport.cmake, because that file automatically runs code when included in Qt5, and we usually don't want to do it. We'll also have to decide how to handle the define_property() calls that are still left in the private QtPlatformAndroid.cmake file. With this fix, Qt example CMake projects that use add_qt_gui_executable should now be buildable. An APK can be created with 'ninja apk'. Unfortunately Qt Creator 4.13 does not currently seem to support opening and building CMake Qt For Android projects properly. While the build succeeds after fiddling with the Kit settings, the APK deploy step fails to run (at least on my machine). So the simplest way to run the built APK is to open the android-build dir with Android Studio and launch the example application from there. Task-number: QTBUG-85399 Change-Id: I77f246331de7a6e9e6d4ba7d973730190138f136 Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: fix android target build not picking the correct sysrootAssam Boudjelthia2020-08-131-8/+8
| | | | | | | | | | This previous way caused target builds under Linux to pick the host packages like udev and mtdev and build for them which they will fail during the build. Task-number: QTBUG-86028 Change-Id: Ic029f0a3e71b50c694473a110922f0ef11e5b0bf Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Protect against Qt toolchain file recursive inclusionAlexandru Croitor2020-06-041-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* pro2cmake.py: Generate .cmake.conf files for versioningMårten Nordheim2020-04-301-1/+2
| | | | | | | | And create one for QtBase at the same time. Fixes: QTBUG-83835 Change-Id: Icc6b022165a57bd4e22c23bdb0016522b99a5b80 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix pkgconfig calls when cross-compilingLeander Beernaert2020-03-261-0/+10
| | | | | | | | | | | | | | When cross-compiling with CMake, before this patch pkgconfig calls would find libraries which are part of the host system and not the target system. The current approach used is based of the discussion present in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4478, and should be considered a temporary solution until the issue is properly addressed in upstream CMake. Change-Id: I535d4d48c2a5d34689082b80501b3b6ae30d7845 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix auto-detection of precompiled header supportAlexandru Croitor2020-03-251-3/+0
| | | | | | | | | | | | PCH files were only used while building qtbase. Make sure the value is exported to the BuildInternalsConfig file, so the value is re-used when building other repositories. Also disable PCH when building simulator_and_device iOS builds, because CMake doesn't currently generate separate PCH files per architecture. Change-Id: I79955ebc557b800bc3c704deac519fe80012c229 Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* cmake: Remove APPLE prefix from platform namesTor Arne Vestbø2020-03-161-1/+1
| | | | | | | None of the other platforms have it. Change-Id: Ib448c2c03ba03f711b507ef391977c0e6aa7c192 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Fix naming when referring to Apple macOSTor Arne Vestbø2020-03-161-1/+1
| | | | | Change-Id: Iafb5e448d0d65d42f788464fc600594a5666f9af Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Add default Info.plist for macOS with some important keysTor Arne Vestbø2020-03-131-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | The default Info.plist shipped with CMake lacks an NSPrincipalClass entry, which is crucial for making macOS apps run in full resolution on retina screens. We make sure the file is only picked up on macOS, not iOS and friends, since those platforms require another principal class. If needed we can extract the value out as a CMake variable and use the same file for all Apple platforms. Doing so would assume all keys are single-platform only, so if that's not the case we need platform-specific files. We should probably extract the package type out as a variable too, so that the file can be used for both apps, plugins, and frameworks, but doing so requires setting up that variable somewhere based on the target type, which CMake doesn't allow in an easy way. The file itself is based on the file CMake ships, combined with keys inherited from Qt's existing plist templates for qmake, and adjusted to match what Xcode generates by default these days. Change-Id: I3f5109e5fff63cdbd109a99d4008948d4bd2102b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix mkspec install commandsLeander Beernaert2020-03-111-3/+8
| | | | | | | | If there is a file present in the globbed mkspecs_subdirs file list we run into an invalid argument error for the install(DIRECTORY) command. Change-Id: I0fe61a8f0a863854f55cf62a87417bcaec1d2c29 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-19 23:14:08 +0000