summaryrefslogtreecommitdiffstats
path: root/cmake/QtBuild.cmake
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* 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-0/+2
| | | | | | | | | | | | | | | | | | 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-0/+5
| | | | | | | | | | | | | | | | | | | | 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>
* Add _qt_internal_wrap_tool_command to replace QT_TOOL_PATH_SETUP_COMMANDAlexey Edelev2021-04-301-0/+15
| | | | | | | | | | | | | | | | | | | QT_TOOL_PATH_SETUP_COMMAND is used in COMMAND list when call add_custom_command/add_custom_target. This is necessary to setup the necessary environment for the tool to run correctly. This approach is weak according to CMake documentation: "If more than one COMMAND is specified they will be executed in order, but not necessarily composed into a stateful shell or batch script." This change introduces the _qt_internal_wrap_tool_command function that uses a wrapping script that setups necessary environment for the tool and runs it in a single shell. The script is generated by the _qt_generate_tool_command_wrapper function. Change-Id: Id5270b91619b607a0c1e3a19b8c706edec43f388 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add Solaris support in cmake buildNiclas Rosenvik2021-04-211-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add SOLARIS cmake platform definition. Add settings for QT_DEFAULT_MKSPEC so that qplatformdefs.h can be found. Solaris has its gssapi symbols in libgss. Solaris supports @ORIGIN. Solaris ld does not support --dynamic-list needed for reduce relocations. Make solaris fail the reduce relocation test. getauxval is specific to GNU libc and some other libc implementations on Linux but sys/auxv.h is not. The bootstrap uses sys/aux.h as the only indication for getauxval. This breaks builds on Solaris, so only make sys/auxv.h an indicator for getauxval on linux or glibc based systems. Solaris uses X11 so add it to the X11_SUPPORTED list. Solaris network libraries for sockets etc are in socket and nsl. ifreq does not have a member ifr_ifindex on Solaris, it uses ifr_index. Add test to check if ifr_index is a member of ifreq. The first struct in the in_addr union on solaris is defined as four uint8_t, therefore four arguments are needed for its initializer list. Change-Id: Ieed4c1bbac8559a7ae1db9c4e1e91f609f150270 Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* wasm: add cmake build supportLorn Potter2021-04-011-1/+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>
* Remove the redundant code related to the QT_NAMESPACE variableAlexey Edelev2021-03-301-5/+0
| | | | | Change-Id: Ib82b199fc7761c8b84f915c2808c7f57bf23927c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Refactor qt_internal_add_plugin() and qt6_add_plugin()Craig Scott2021-03-291-22/+37
| | | | | | | | | | | | | | | | | | | | | | Remove code duplication by calling qt6_add_plugin() from qt_internal_add_plugin(). Separate out the public and internal arguments for the variables defined in QtBuild.cmake for these functions. Provide them via commands instead for greater robustness. This separation allows other Qt repos to access the appropriate set of keywords where they define commands that forward on to *_add_plugin() in their implementations. Retain the old variables for now to simplify the integration steps for updating other repos. The old variables can be removed once there are no more references left to them in any repo. Task-number: QTBUG-88763 Pick-to: 6.1 Change-Id: I0105523afd95995923bd20fc963d245bbb15d34d Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Set QT_DEFAULT_MKSPEC for various bsd systemsNiclas Rosenvik2021-03-191-0/+10
| | | | | | | | | Set QT_DEFAULT_MKSPEC for various bsd systems, this is needed to find qplatformdefs.h when compiling. Change-Id: I9450193b737930548f32c87be3525c5ecd1e0e13 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* qtdeclarative now directly handles more qml-specific logicCraig Scott2021-03-101-1/+0
| | | | | | | | | | | | | | | | | Associated changes in the qtdeclarative repo now ensure that arguments for qml plugins are handled on the calling side. This reduces the qml-specific logic needed in qtbase and gives qtdeclarative clearer control over qml build and install locations. As part of that work, the INSTALL_LOCATION keyword used in qt_internal_record_rcc_object_files() has been renamed to INSTALL_DIRECTORY to make it consistent with the keyword used for the same concept in other commands. Pick-to: 6.1 Change-Id: Iebd319899f63d79fbe15ce965b84ce324c28a508 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Use Core library for qmake instead of the Bootstrap libraryAlexey Edelev2021-02-251-1/+0
| | | | | | | | | | | | | | | | | | | Move the qmake-specific logic of the QLibraryInfo class to qmake internals. 'qconfig.cpp.in' now stores information about the library info entries to keep them consistent between qmake and the Core library. qmake requires specific features enabled in the Core library, so building qmake will be skipped if the features are not enabled. All flags directly related to the qmake have been removed from Core lib. Remove all bootstrap related sections from qmake CMakeLists.txt Task-number: QTBUG-89369 Change-Id: I26de157d3bfd4a5526699296e9d46e1c180b89ae Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* CMake: Reformat shared keyword listsCraig Scott2021-02-241-12/+63
| | | | | | | | | | | | Putting each keyword on its own line makes it much easier to read and improves maintainability. It is friendlier to source control when keywords need to be added or removed. This commit introduces no functional change. Pick-to: 6.1 Change-Id: I79efd039e5afa5f11f1d859405d6487ad6b3beb2 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: setup windows tools path only when building on WindowsSamuli Piippo2021-02-111-1/+1
| | | | | | | | | | | Fix cross-compilation on Linux host. Task-number: QTBUG-91052 Pick-to: 6.1 Change-Id: I48c970f0e6af71e3eda3818557e764f60d3836ad Reviewed-by: Juha Vuolle <juha.vuolle@insta.fi> Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Rename QML2 imports to QML importsUlf Hermann2021-02-081-1/+1
| | | | | | | | The 2 is meaningless. Task-number: QTBUG-85064 Change-Id: Ic91872804be266d50224fb272b4f4836573f4bf7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Fix QT_TOOL_PATH_SETUP_COMMANDJuha Vuolle2021-01-271-1/+1
| | | | | | | | | | | | | | Commit 18fc9e1bf821130f0cfe45dc7d5c05b70458e7c0 introduced a Windows-only QT_TOOL_PATH_SETUP_COMMAND to make it possible to call the tool of a module while building the module itself. The "set PATH=..." command in QT_TOOL_PATH_SETUP_COMMAND was flawed, because it contained escaped double quotes which made the set command ineffective. Fix this by removing the escaping of the double quotes. This was uncovered when porting qtscxml to CMake. Change-Id: I5909aa841e7895d6d0feb4037a935b805ccfdc99 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Fix invalid Qt prefix version when looking for HostInfo moduleAlexey Edelev2021-01-261-11/+0
| | | | | | | | | | | | | | | | | | | In QtSetup.cmake the PROJECT_VERSION_MAJOR variable was used to identify prefix of 'Qt<version>HostInfoConfig.cmake'. Qt<version>HostInfo is not found, if project version differs from qtbase version. Move the 'INSTALL_CMAKE_NAMESPACE' and 'QT_CMAKE_EXPORT_NAMESPACE' variables to 'QtBuildInternalsConfig.cmake'. In this case variables will be exposed for a wider list of internal routines. Use the 'INSTALL_CMAKE_NAMESPACE' variable as prefix to find Qt<version>HostInfo module. Fixes: QTBUG-90345 Change-Id: Ic595d1c5beb74f34e69b58e18590a3afc2f346f7 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Move UNICODE and _UNICODE definitions to internal platform targetAlexey Edelev2021-01-191-1/+1
| | | | | | | | | | Move UNICODE and _UNICODE definitions from the public Qt::Platform target to the private Qt::PlatformCommonInternal target. Fixes: QTBUG-89951 Change-Id: Ib4c1c4cab74acda0a43c4ddb3cffd3954393dc89 Reviewed-by: Kai Koehne <kai.koehne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* CMake: Use cmake_language(DEFER) when available for scope finalizersAlexandru Croitor2020-11-251-2/+5
| | | | | | | | | | | | | | If CMake version is 3.19 or greater, use cmake_language(DEFER CALL) for Qt internal scope finalizers, instead of the homegrown implementation. Apart from not depending on the hacky homegrown solution, it significantly improves the readability of --trace-redirect logs. Pick-to: 6.0 Task-number: QTBUG-77377 Change-Id: I5ce374bb313865662c536826e86052bc762438b9 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Rename QtBuildInternalsAndroid.cmake to QtAndroidHelpers.cmakeJoerg Bornemann2020-11-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | ...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>
* QNX7.1 updatesMarianne Yrjänä2020-11-201-1/+1
| | | | | | | | Updates due to newer compiler version in QNX7.1 Task-number: QTBUG-88300 Change-Id: If9bbc08d49a077d80174a1807e069b5d4ef61c0d 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: Fix installation errors in multi-config buildJoerg Bornemann2020-11-101-1/+1
| | | | | | | | | | | In multi-config builds (which equals the debug-and-release feature) we exclude tools of the non-main configurations from the default build. But we still create installation rules for them. Mark those as optional to avoid "cmake --install" yielding errors if those tools weren't built. Fixes: QTBUG-85411 Change-Id: Ic2d3897d1a1c28a715d9a024ec8606fff00e0315 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Yield fatal error on malformed INSTALL_MKSPECSJoerg Bornemann2020-10-301-0/+4
| | | | | | | | The value of this variable must be exactly "mkspecs" or end with "/mkspecs". Change-Id: I39f83e9660794dfe23f5fd39fb1084b87ba1f140 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: 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>
* win: Set correct target mkspec for qmake builds for arm64 buildsOliver Wolff2020-10-091-1/+5
| | | | | | | | | | As there is no other way of obtaining information about Qt's paths at the moment, windeployqt is still querying qmake for these information. For a cross compiled Qt, the proper target mkspec has to be set in this case. Change-Id: I0b7b7719c9055d432576185ac4f7572a5ba1dd6b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix leftover usage of qt_add_executableAlexandru Croitor2020-10-071-5/+5
| | | | | | | | | | | All usages should be replaced with qt_internal_add_executable instead. This should fix configuration failure of benchmarks and manual tests. Amends e0c62a48b8a826a46a143e57e94b2a0ea73c7cae Task-number: QTBUG-86815 Change-Id: I0791d849998ed9517e32f699d843367949b97cb9 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-03 06:18:03 +0000