summaryrefslogtreecommitdiffstats
path: root/cmake/QtBuild.cmake
Commit message (Collapse)AuthorAgeFilesLines
* CMake: Mostly unify includes into a single locationAlexandru Croitor2023-11-271-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Split QtBuild.cmake into smaller files v2Alexandru Croitor2023-11-271-581/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My motivation to do this: - it got big and tangled again - sometimes functions need to be added to QtBuild.cmake rather than to a separate file because they need to be called before some of the global variables are set, to determine the value of those global variables (in my case install paths needed to be modified when building with xcframework support) - some of the global variable assignments have dependencies on other variables already being set and it's hard to keep track where that happens Split the contents of the file into smaller functions and macros and place them into pre-existing files when appropriate, or into new files. The new files are: - QtBuildHelpers.cmake - QtBuildPathsHelpers.cmake - QtMkspecHelpers.cmake The idea is to have Helpers file only define functions and never call them, so it's easy to include the file where needed without being scared of side effects. QtBuild.cmake will just include the helpers and call one entry point function to set up everything that was done by the file before. QtBuild.cmake is not merged into QtSetup, to make it easier to git blame (it's hard to blame a removed file). No new features were added as part of the refactoring. Some function names were renamed (but not all of them) to include the qt_internal prefix. Some lines were reformatted so they don't pass 100 chars limit after the code was placed into a function / macro. The Helpers includes were re-sorted. Some function calls were re-ordered where the order call didn't matter. Some of the code in QtAndroidHelpers.cmake was wrapped into a macro so that including the file does not cause side-effects by default. I'd like to follow up with similar changes for QtSetup.cmake and QtBuildInternalsConfig.cmake where possible, because having a few "entry points" into building a Qt submodule is also confusing, especially for those that aren't familiar with the build system and why certain things go into certain places. The intent is to cherry-pick this also to 6.5 and 6.6. Amends 44cce1a2ea9dadd8b2de93f40de34269dda703c0 Task-number: QTBUG-86035 Change-Id: I02ceff8ceb9b6e9c78bc85d6a42deb02fca3e46b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Orkun Tokdemir <orkun.tokdemir@qt.io>
* Fix running CMake test projects in prefix buildsJoerg Bornemann2023-08-191-0/+1
| | | | | | | | | | | | | | | | | | | | | 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 helpers: support NO_PCH_SOURCES wherever NO_UNITY_BUILD_SOURCES areMarc Mutz2023-08-071-0/+1
| | | | | | | | | | | The former implies the latter, so it makes little sense to treat them differently. Even if some types of targets are (currently) never compiled with PCH, users of qt_internal_all_x() shouldn't need to know such details. Pick-to: 6.6 6.5 Change-Id: I8ead238a8d9e55da632b2929638b67724a42d73c Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Use QT_64BIT instead of checking CMAKE_SIZEOF_VOID_PAmir Masoud Abdol2023-06-161-1/+1
| | | | | | Pick-to: 6.6 Change-Id: I7db7b8f6c354df264a467538fffffab726ea1b61 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Fix Clang platform detecting mechanismAlexey Edelev2023-05-311-8/+8
| | | | | | | | | | | | | CMake not necessarly sets MSVC or MINGW when detecting Clang compiler. We should rely on CMAKE_CXX_COMPILER_FRONTEND_VARIANT instead when detecting Clang platform. Fixes: QTBUG-113630 Pick-to: 6.5 6.2 Change-Id: I8c14939ddc0839ddf2b3419392aa843deeef4bb5 Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Make sure that QT_QMAKE_TARGET_MKSPEC is not emptyAlexey Edelev2023-05-231-3/+11
| | | | | | | | | | | | | | | If target platform is not detected the QT_QMAKE_TARGET_MKSPEC variable remains empty. We need to check this explicitly. Also store the default QT_QMAKE_TARGET_MKSPEC variable in the target toolchain file. This is useful if users want to build repos one-by-one or build standalone tests without the need to specify the QT_QMAKE_TARGET_MKSPEC each time when configuring new repo or tests. Task-number: QTBUG-113630 Pick-to: 6.5 6.2 Change-Id: I57dfc6c97752a645868d77998d8f52e16bdfd5c8 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Allow building with llvm-clang in macOSKuntal Majumder2023-03-061-1/+1
| | | | | | | | | | Supressing the linking warnings on macOS are relevant when we are using AppleClang and not upstream Clang. The provided arguments do not apply to llvm-ar and llvm-ranlib. Change-Id: I8b664c01802b47077eb0ab80dab7681ee0bfcaa9 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Add some utilities for UNITY_BUILDAmir Masoud Abdol2023-02-081-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | - The following commands accepts NO_UNITY_BUILD, and NO_UNITY_BUILD_SOURCES arguments to opt out of the unity build, and to exclude some source files from unity build, respectively. - qt_internal_add_executable - qt_internal_add_module - qt_internal_add_plugin - qt_internal_add_tool - qt_internal_extend_target - qt_internal_add_common_qt_library_helper - qt_internal_add_cmake_library - qt_internal_add_simd_part - Unity build is disabled by default in these: - qt_internal_add_test - qt_internal_add_test_helper - qt_internal_add_benchmark - qt_internal_add_3rdparty_library - qt_update_ignore_pch_source also excludes the files from unity_build Pick-to: 6.5 Task-number: QTBUG-109394 Change-Id: I5d0e7df633738310a015142a6c73fbb78b6c3467 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Retire the qt_parse_all_argumentsAmir Masoud Abdol2023-01-181-3/+5
| | | | | | | | | | | This replaces the qt_parse_all_arguments macro with the built-in `cmake_parse_arguments(PARSE_ARGV`. In addition, a new function, _qt_internal_validate_all_args_are_parsed, can be used to check whether any _UNPARSED_ARGUMENTS have been passed to the function. Fixes: QTBUG-99238 Change-Id: I8cee83dc92dc6acdaaf747ea6ff9084c11dc649b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove an unnecessary call to _qt_internal_generate_tool_command_wrapperAmir Masoud Abdol2023-01-161-5/+0
| | | | | | | | | Alexandru mentioned that at the time qtdeclarative was still using the variable, but from then, he replaced those as well, and I couldn't find any usage anymore either. Change-Id: I6a1893c2dfaa483dc8cb865f7bacf08cadca985b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Install module JSON files to INSTALL_ARCHDATADIR/modulesJoerg Bornemann2022-12-091-1/+1
| | | | | | | | | | | | The module description JSON files contain architecture-specific information. Therefore they should reside below INSTALL_ARCHDATADIR instead of INSTALL_DATADIR. Moving these files should be unproblematic as there are no known users of these files. Change-Id: Ibff1f7b6ce2d1633ebce33861358ad5d1cae2beb Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* wasm: add support for wasm64 buildLorn Potter2022-12-071-1/+5
| | | | | | | | | | | | | | This adds a new platform named wasm-emscripten-64 which sets the build and link argument -MEMORY64 You may see this warning, please ignore at your own discretion: em++: warning: -sMEMORY64 is still experimental. Many features may not work. [-Wexperimental] Fixes: QTBUG-104891 Change-Id: I8d3150d239ba72dbef5c2352e0171d6cfbe51b59 Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
* Remove perl related functionality from CMake filesAlexey Edelev2022-11-291-4/+0
| | | | | | | | | Avoid using perl in CMake scripts. Remove the syncqt.pl specific code. Task-number: QTBUG-87480 Change-Id: I7fcd5cc83d173ec463c275b5b50b84f25044a118 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: add SYSTEM_INCLUDE_DIRECTORIES to qt_internal_extend_targetThiago Macieira2022-11-281-0/+1
| | | | | | | | | | | | This allows one to add an extra set of directories to the build, but let the compiler know that they are system paths (that is, the compiler should refrain from emitting warnings in code found there). This extends INCLUDE_DIRECTORIES and is by necessity a private include set. Will be used by qtquick3dphysics, due to its PhysX dependency. Change-Id: I76216ced393445a4ae2dfffd1729c556db0cce3d Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Replace the syncqt.pl script with syncqt toolAlexey Edelev2022-09-271-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | syncqt.pl adds an extra dependency on perl when building Qt. Modern C++ provides the convenient cross-platform way to access a filesystem and to use regular expressions, so we may replace the perl script with C++ application. The syncqt executable is built at configure time and installed as QtCore tool. It's running at configure time to deliver the required header files for IDE to build a consistent code model and at the build time to keep tracking changes in header files and generate the missing aliases without reconfiguring. 'syncqt' only parses header files from a CMake build tree, so the resulting Qt installation only contains interfacing headers that belong to the platform that Qt is built for. 'sync.profile' files are not used as the 'source of truth' for sync qt procedure anymore, all the necessary information is taken from either CMake files at configure time or from the module header files while parsing them. syncqt.pl is still in place since it's required as fallback solution for a smooth transition to the new syncqt implementation for all qt repositories. This patchset only enables the C++ based syncqt for 'qtbase' repository. From the performance perspective C++ version works faster then perl script, also the configure time is reduced significally on subsequent reconfigurations - up x2 times faster when re-configuring repository, but it also takes time to compile the tool itself the first time. Numbers for qtbase: syncqt.pl syncqt.cpp initial: 0m16,035s 0m20,413s reconfig: 0m6,819s 0m3,725s The syncing procedure can be run separately for each module using <ModuleName>_sync_headers targets. The 'sync_headers' target can be used to sync all the modules at once. Task-number: QTBUG-87480 Task-number: QTBUG-103196 Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add function to get tool wrapper shell script pathAlexandru Croitor2022-09-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | The _qt_internal_wrap_tool_command function has a limitation that it is not possible to use it when a command needs to be wrapper in a generator expression. Provide a lower level API called _qt_internal_get_tool_wrapper_script_path to just get the path to the wrapper script, ensuring that the script is created if needed. Deprecate _qt_internal_wrap_tool_command, in favor of replacing it with the new API. Pick-to: 6.4 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: Ie4a4a17178bf2061ae01ee2b03b052d84560abf9 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Rework tool wrapper shell script creationAlexandru Croitor2022-09-151-17/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of creating the tool wrapper shell script only during a Qt build in QtBuild.cmake, ensure it is created any time _qt_internal_wrap_tool_command is called, regardless if we're building Qt or a user project. As a transitional period not to break compatibility, we also need to create the script in QtBuild.cmake, until all usages of QT_TOOL_COMMAND_WRAPPER_PATH are replaced with function calls. Currently such usages are present in qtdeclarative. When considering which bin dirs to add to the script's PATH environment variable assignment, in addition to the build internals relative bin dir, also add QT_BUILD_DIR, QT_ADDITIONAL_PACKAGES_PREFIX_PATH and QT6_INSTALL_PREFIX. QT_BUILD_DIR is important so we always pick up the just-built but not installed libraries in a prefix build when running just-built tools. QT_ADDITIONAL_PACKAGES_PREFIX_PATH is important when building examples as ExternalProjects in prefix builds, to ensure that the not-yet-installed tools and libraries are picked up from the repo build dir, which is passed via QT_ADDITIONAL_PACKAGES_PREFIX_PATH to the external projects. QT6_INSTALL_PREFIX is there in case if the build internals relative dir is located in a different places than the Qt6 package. Pick-to: 6.4 Task-number: QTBUG-90820 Task-number: QTBUG-96232 Change-Id: I4d76fbbc275ca961379971054f87991adac36539 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Move Apple specific functions into a separate fileAlexandru Croitor2022-08-301-0/+1
| | | | | | | | Pick-to: 6.4 Task-number: QTBUG-95838 Change-Id: Ib0ce53fe0e2068482b654921ecba3232efe656c8 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* Change the license of all CMakeLists.txt and *.cmake files to BSDLucie Gérard2022-08-231-1/+1
| | | | | | | Task-number: QTBUG-105718 Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Move _qt_internal_create_command_script to a public fileAlexandru Croitor2022-08-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | It's needed for creating qmake build tests. CMake / CTest has a limitation of not allowing to create single-config tests when using a multi-config generator using the add_test(NAME) signature. Using add_test(NAME) forcefully creates per-config tests, which means that it's not possible to just run ctest to execute tests, without specifying a -C parameter, which we do in the CI. qmake tests need to use the add_test(NAME) signature to specify the WORKING_DIRECTORY option. Because of the above limitation, a work around is to not use the add_test(NAME) signature, but instead delegate the working directory assignment to a generated cmake script, which _qt_internal_create_command_script can already do. Pick-to: 6.4 Task-number: QTBUG-96058 Change-Id: I6f439165994671724157f0edb7a71e351271e329 Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Make wasm finalizers work for standalone tests and other reposMikolaj Boc2022-08-151-0/+4
| | | | | | | | | | | | The wasm helpers file is not included in QtBuild and is thus not visible when standalone tests or other repos are being built. This fixes it. Amends 1f9c1f032c5d8af2c6758081eb8de076fe678b53 Pick-to: 6.4 Fixes: QTBUG-105615 Change-Id: I6c9229e1f259fa5043d7d11b8ee0293e26077f3e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add license headers to cmake filesLucie Gérard2022-08-031-0/+3
| | | | | | | | | | | | CMakeLists.txt and .cmake files of significant size (more than 2 lines according to our check in tst_license.pl) now have the copyright and license header. Existing copyright statements remain intact Task-number: QTBUG-88621 Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Remove internal __qt_add_plugin_*_args variablesJoerg Bornemann2022-08-031-37/+0
| | | | | | | | All references to these variables have been removed from Qt repositories. Change-Id: Icca4668ec183ff543d04097600f8a8869066f8cc Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Improve Qt6HostInfo package lookup conditionAlexandru Croitor2022-07-251-1/+2
| | | | | | | | | | | | | | | | | | | Instead of checking if QT_HOST_PATH is set during user project configuration to find out if Qt6HostInfo should be looked up, record if QT_HOST_PATH was provided during Qt configuration into Qt6Dependencies.cmake and look up the package in a user project based on that information. This improves handling of the case where cmake is directly used to configure a Qt project (instead of qt-cmake), which means no QT_HOST_PATH might be set by the user, and then cmake would error out saying that e.g. Qt6CoreTools is not found, instead of saying that Qt6HostInfo is not found. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: I0377d5440e4b5b295af73cfd4b5188f61d48e440 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Move Qt6HostInfo lookup into a functionAlexandru Croitor2022-07-251-0/+8
| | | | | | | | | | | | | | | Also replace the duplicate call in QtSetup using the new function. To do that, we have to actually the call it in QtBuild after QtPublicDependencyHelpers.cmake is available. That call is needed so that Qt6_HOST_INFO_foo variables are available in qt_generate_qmake_and_qtpaths_wrapper_for_target. Pick-to: 6.4 Task-number: QTBUG-104998 Change-Id: Ic5776c214bee6bedcea714b213b0e5a42c1bae06 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Fix typosKai Köhne2022-06-131-1/+1
| | | | | | | | Found by codespell Pick-to: 6.4 Change-Id: I4907e423b6b345acf82f2d7e0ed62479719d694e Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake: Make possible building Qt tools without the use of core libraryAlexey Edelev2022-05-061-1/+1
| | | | | | | | | | | | | | Replace BOOTSTRAP option with the single value CORE_LIBRARY argument in qt_internal_add_tool and qt_internal_add_executable functions. The introduced argument now may accept 'Bootstap' and 'None' values. Use 'Bootstap' to link Qt::Boostrap library instead Qt::Core or 'None' to avoid any core library linking. This is useful for tools that need to use the CMake deployment routines, but not require the Qt::Core functionality. Task-number: QTBUG-87480 Change-Id: I64a8b17f16ac5fe43c6b385252dc21def0c88d2c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Disable CMAKE_INSTALL_RPATH_USE_LINK_PATHAlexandru Croitor2022-04-191-11/+9
| | | | | | | | | | There should be no need for CMake to add rpaths pointing to directories outside of the build tree to the installed libraries. All relevant install rpaths are handled by qt_apply_rpaths(). Change-Id: If554b1e3c790c2bb04a34e8b0524aab3febf5afc Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Allow no install + custom on-device prefix for desktop buildsAlexandru Croitor2022-04-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow such a combination - staging prefix (CMAKE_STAGING_PREFIX / -extprefix) set to the qtbase build dir - install prefix (CMAKE_INSTALL_PREFIX / -prefix / on-device prefix) set to some custom location even for non-cross builds. An example would be configure -prefix /usr \ -extprefix ~/qt/qtbase_build_dir CMake will put the Qt libraries in the qtbase build dir, ninja install will not be required, but ultimately in order to run applications, the Qt libraries are expected to be in /usr. Support for this scenario was originally added for cross-builds in 062318feb2d3b7598409c7e81e4459c2f4607764 , but not desktop builds. Such a build is useful when you want to have install rpaths different from where Qt is initially installed to (the staging prefix). This case doesn't really happen often when targeting desktop platforms, it's mostly used for cross-compilation (e.g yocto). Being able to have the same setup with a desktop build is nevertheless useful for faster iteration on build system issues in such a scenario. Amends 062318feb2d3b7598409c7e81e4459c2f4607764 Pick-to: 6.2 6.3 Change-Id: I42be3628a30025f14eebaf0a79401b54e95cde26 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
* CMake build: generate pkgconfig for public modulesMartin Reboredo2022-02-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the update to the CMake based build system the ability to generate pkgconfig files, like it was with QMake, was lost. This patch adds pkgconfig generation again via a new internal command named qt_internal_export_pkg_config_file. The functionality of this command consists in checking if the target is internal. Then gets the compile definitions. It performs a search for dependencies that is somewhat similar to qt_get_direct_module_dependencies, although it won't recurse down for more deps. Each dependency is then again, checked if it's internal or has a public interface. Later these deps get deduplicated and lastly a pkgconfig file is filled. The resulting pkgconfig files of many of the Qt6 packages were validated via invocations of `pkg-config --validate` and `pkg-config --simulate` commands and later used to build local projects plus tests that use the pkg-config provided details at compilation time. Although it has some limitations, with qt_internal_add_qml_module if it specifies non-public deps these won't be listed and with non-Qt requirements, notably in static builds, not being appended to the PkgConfig file. Task-number: QTBUG-86080 Change-Id: I0690bb3ca729eec328500f227261db9b7e7628f6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add missing include of QtPublicCMakeHelpersAlexey Edelev2022-02-101-0/+1
| | | | | | | | | | Amends 2201934efa1b9889d474347e705784bf6925e120 Pick-to: 6.2 6.3 Task-number: QTBUG-99491 Change-Id: I449f0705f1e41fd4609008ae6a7f4107cd0a4ca6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
* CMake: Fix rpath set for Qml plugins to not contain lib64Alexandru Croitor2022-02-031-0/+5
| | | | | | | | | | | | | | | | | | | | | Qt6QmlMacros uses the value of GNUInstallDirs's CMAKE_INSTALL_LIBDIR to calculate the rpath from a Qml plugin's location to the Qt libraries. By default CMake detects the value of CMAKE_INSTALL_LIBDIR, and on an RHEL system it is set to 'lib64', whereas we usually configure Qt with the lib dir set to just 'lib'. This might cause issues with Qml plugins not locating the Qt libs due to an incorrect rpath. Ensure that when building Qt libraries and plugins, CMAKE_INSTALL_LIBDIR is set to the same lib dir value that Qt was configured with. Pick-to: 6.3 Fixes: QTBUG-99707 Task-number: QTBUG-100432 Change-Id: I17b2a22d46ef3b40084a2f6a4992f0e23b35d4d3 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Use IMPORTED_LOCATION of rcc targetAlexey Edelev2022-02-011-0/+1
| | | | | | | | | | | Use IMPORTED_LOCATION of rcc target when generating Android deployment settings, instead of the hardcoded host path. Introduce a helper function to find the location of the imported tool target. Change-Id: Icfa51ee7a01b3f58fc4892da03055f9ed531cc0b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: add support for GNU/HurdPino Toscano2022-01-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | Add a "HURD" CMake platform specification, so it can be properly checked in the build system. Set QT_DEFAULT_MKSPEC to the existing hurd-g++ mkspec. Hurd supports $ORIGIN in RPATH, so enable it. Hurd uses X11, so add it to the X11_SUPPORTED list. Enable few more feature checks that apply to Hurd as well: either because they are provided by GNU libc itself, or because they are implemented on Hurd. Check and set the ELF interpreter, as it is a common functionality of the GNU toolchain. Change-Id: Id347033560bbc5a2a4e2c3abb493c948c002b40e Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix errors about missing qt_setup_tool_path_command.bat.inJoerg Bornemann2021-12-151-3/+3
| | | | | | | | | | | | | | | | This amends commit 0bea727cac6b22af05e0ae68b02de6684c98667b or rather reverts it and applies a different fix for QTBUG-98843. Use file(WRITE) instead of configure_file or file(CONFIGURE). This command doesn't have the line endings issues in CMake 3.19 (see QTBUG-98843). It's not problematic that the .bat file gets a new timestamp on every configuration step, since we don't add dependencies on it. Fixes: QTBUG-99223 Task-number: QTBUG-98843 Change-Id: Ibdcd0e4703bf6df42c6a6d0bb2f35c5144bbe30a Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Fix build on Windows with CMake 3.19Joerg Bornemann2021-12-131-10/+3
| | | | | | | | | | | | | | | | qt_setup_tool_path.bat did not have proper line endings on Windows with CMake 3.19, breaking the invocation of tools that use the wrapper, for example qmltyperegistrar. The reason was that file(CONFIGURE) doesn't properly write line endings with CMake 3.19. See upstream issue #21769. Use configure_file with a proper input file to work around this issue. Pick-to: 6.2 Fixes: QTBUG-98843 Change-Id: I2a4da15f306dc844cf83ca9721a77196c42af2ad Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Bump WINVER, _WIN32_WINNT and _WIN32_IE to _WIN32_WINNT_WIN10 (0x0A00)Yuhang Zhao2021-11-101-1/+1
| | | | | | | | | | | And bump NTDDI_VERSION to 0x0A00000B (NTDDI_WIN10_CO) at the same time, to unblock the developers from accessing the latest Windows APIs. Pick-to: 6.2 Change-Id: Ifbc28c8f8b073866871685c020301f5f20dc9591 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>
* Improve double call protection of qt_internal_generate_tool_command_wrapperAlexey Edelev2021-10-151-4/+15
| | | | | | | | | | | | | | | | | | file(GENERATE) might fail if an unrelated configuration error happens, and yet QT_TOOL_COMMAND_WRAPPER_PATH would already be set. Set the cache variable only if generating was successful and replace the QT_TOOL_COMMAND_WRAPPER_PATH valiable check with GLOBAL property to protect the function from double call. For CMake versions higher than or equal to 3.18 replace 'file(GENERATE' call with 'file(CONFIGURE' to generate the wrapper at configure time with the use of a plain semicolon character. Pick-to: 6.2 Fixes: QTBUG-96870 Change-Id: Icf9c40f571d9c069043604f67ffcf2762966f6d0 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: remove support for building Qt with the old Intel compilerThiago Macieira2021-10-131-2/+0
| | | | | | | | | | | | | | | | | | This hasn't worked for some time. It's not in our CI and I don't think it was working at all. When I tried to build it, I ran into several problems with C++17 and an Internal Compiler Error I did not have any interest in working around. After discussing with the Intel compiler team, it was decided that fixing those issues in the old compiler is not going to happen. Instead, their recommendation is to adopt the new LLVM-based compiler, which the last commit added support for. This commit does not remove qmake support for the old ICC. It's possible someone is using qmake with a non-Qt6 project and ICC. Change-Id: Icb2516126f674e7b8bb3fffd16ad6350ddbd49e5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove unused EXE_FLAGS option from qt_internal_add_executable()Craig Scott2021-09-181-1/+0
| | | | | | | | | | The EXE_FLAGS option wasn't being used anywhere in any Qt repo and it had no documentation as to its intended use. Remove it. Pick-to: 6.2 Change-Id: I2f67ec57c1da7dc6eab81d5351361e770d19d7d5 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't cache QT_SYNCQT across buildsJoerg Bornemann2021-09-031-4/+0
| | | | | | | | | | | | | | | | | | | | | | There is no need for this variable to be stored in CMake's cache. We don't perform expensive operations to set up QT_SYNCQT, and we even unset the cache variable to ensure it gets recomputed on reconfiguration. We still store QT_SYNCQT in a global property, because the function qt_ensure_sync_qt is called in different directory scopes, and we want to avoid re-calculations for every subdir. It's now possible for the user to set QT_SYNCQT (see QTBUG-88088 for motivation). Also, in a non-prefix build, changes to syncqt.pl in the source dir are reflected upon re-configuration in the build tree (because qt_copy_or_install is called on every configure). Pick-to: 6.2 Fixes: QTBUG-88088 Task-number: QTBUG-75290 Change-Id: I6137b060d200d3dafd4a64d5a6c1bd2549723d78 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Move the logic associated with platform definition directoryAlexey Edelev2021-07-131-26/+0
| | | | | | | | | | | | | | | | | | Since platform definition directory is used as an interface include path of the Qt::Platform target, it makes sense to define it for this target only. Also the definition of cached values that contain path to platform definition looks redundand. The definition of QT_PLATFORM_DEFINITION_DIR from command line doesn't make any sense since build procedure doesn't take it into account when installing mkspecs and the use if the user-provided QT_PLATFORM_DEFINITION_DIR value as a Qt::Platform include directory causes inconsistency in the prefixed builds. INSTALL_MKSPECSDIR and QT_QMAKE_TARGET_MKSPEC should be used instead. Change-Id: I3636c57b835cb84511a358a0910cc482c5fbd81e Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix platform definition directory in top-level buildAlexey Edelev2021-07-071-1/+1
| | | | | | | | | | | | | | QT_BUILD_DIR should be used instead of CMAKE_BINARY_DIR as a base directory for platform definition when building a non-prefixed build since artifacts are copied to qtbase directory for top-level build. Amends 478f5fcde66a49b710c427447916a0ee0e4d9e0a Pick-to: 6.1 6.2 Task-number: QTBUG-94973 Change-Id: I5cce16fdc7f760b954222ae67a4b85d4beea7f13 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix the detection of platform definitions directoryAlexey Edelev2021-07-051-25/+33
| | | | | | | | | | | | | | | | | | Platform definition directory is defined when building qtbase. Depending on the build type (prefixed/non-prefixed) it should point: - To the source directory when building prefixed qtbase. - To the installation directory of the prefixed qtbase when building consumer projects. - To the build directory of non-prefixed qtbase when building non-prefixed qtbase or consumer projects. TODO: It is desirable to move the logic asssociated with Qt platform definition to the qt_internal_setup_public_platform_target function. Pick-to: 6.1 6.2 Fixes: QTBUG-94973 Change-Id: I8530613f9b2029834c66206bbdf02475528a4640 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Throw FATAL_ERROR if specified platform doesn't existAlexey Edelev2021-06-251-0/+11
| | | | | | | | | | | If user specifies non-existing platform build fails in some non-obvious place, since qplatfromdefs.h couldn't be found. Add an explicit error if the defined platform folder doesn't exists in Qt sources. Change-Id: Id847d57a6f9cc4f463e697b474b8a669cd041fb8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Move dependency lookup functionality to the common macroAlexey Edelev2021-06-191-1/+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>
* 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>
* CMake: Add support for building with clang-clCristian Adam2021-06-041-1/+3
| | | | | | | | | qmake had support for building with clang-cl as the win32-clang-msvc mkspec. Task-number: QTBUG-89642 Task-number: QTBUG-88081 Change-Id: I0709c289f90fedb121620d1e67ef841602219816 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-08 07:08:45 +0000