summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
...
* Add _qt_module_interface_name for 3rdparty librariesAlexey Edelev2021-05-231-0/+3
| | | | | | | | | | | Since we add 3rdparty libraries to the set of the Qt modules, they are treated as the Qt modules by the depenedcy helper as well. So give them _qt_module_interface_name to fix dependency helper. Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Change-Id: I5898c1c90156de1878aeeef5a0924349b44c50fa Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Add export of the Private targets for the internal modulesAlexey Edelev2021-05-221-8/+6
| | | | | | | | | | | We need to export the Private targets of the internal modules to keep compatibility with existing internal module users across repositories. Amends 425ff34aa10a02524f2d52f544dc00b539ef9a26 Fixes: QTBUG-93943 Change-Id: I10234cec1eb618b69d041f80fbe29620a4e307b9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* qmake: Pick default architecture on macOS based on unameTor Arne Vestbø2021-05-211-0/+7
| | | | | | | | | | | | | | | | | | | | | | | When dealing with a universal build of Qt, we would end up using the QT_ARCH as the architecture for user projects, but this architecture is always the primary one that Qt was configured with. Instead of relying on QT_ARCH, we start writing QT_ARCHS (plural) to qconfig.pri, based on CMAKE_OSX_ARCHITECTURES, and then use that to initialize QMAKE_APPLE_DEVICE_ARCHS. We then resolve the active arch using uname -m, matching what CMake does. We still feed all the available architectures to the Makefile or Xcode project, so that the user can build for any of the available architectures without needing a reconfigure. Fixes: QTBUG-93760 Change-Id: I0d338241ba4d944ca36d85371e9c4df7dbc4f269 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Enable UNICODE for all Qt targets and Qt consumers by defaultAlexey Edelev2021-05-213-8/+16
| | | | | | | | | | | | | | | | | | After discussion we decided to opt-out the UNICODE definintion behavior. To disable UNICODE in user projects the qt6_disable_unicode_defines function could be used. Amends 5b64e5950cf984abb7d47e0802bcb4b5a21e06fa [ChangeLog][CMake] Enables the UNICODE and _UNICODE definitions on WIN32 platforms by default for all cmake projects to reflect the qmake behavior. Use qt6_disable_unicode_defines function to disable the default unicode definitions. Pick-to: 6.1 Fixes: QTBUG-93895 Change-Id: Id70ff7dcf8c74f660ec851f8b950e1e3b94d9fb4 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Do not expose Qt internals by the HEADER_MODULEsAlexey Edelev2021-05-201-1/+2
| | | | | | | | | | | | | | | | | | HEADER_MODULEs use the INTERFACE visibility to link libraries. This causes a transitional propagating of the Qt-internal compile definitions and options to the user targets. This commit avoids an implicit adding of the Qt::PlatformModuleInternal library to the HEADER_MODULEs and stops propagation of the Qt-internal compile definitions and options. If module wants the transitional propagation of some properties, this needs to be done explicitly. Amends 8b7894cb637d21d8fa9bd129849cd23462632d28 Pick-to: 6.1 Fixes: QTBUG-89951 Change-Id: Ia9cecc38bac98eb5bc6e47d288308b49813ab5ac Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Merge main and private targets of the internal modulesAlexey Edelev2021-05-207-83/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In cmake, targets are used as an entity for modules. This causes a number of problems when we want to manipulate a module as a separate entity with properties associated with it. The _qt_internal_module_interface_name target property is introduced to represent the module entity. All modules write a name to this property, which will subsequently expand into the module name matched with the module name in qmake. The 'qt_internal_module_info' function is responsible for providing the correct values ​​for the module properties used when working with a module target. Unlike qmake, for internal modules in cmake it is expected that the Private suffix will be specified explicitly. In case the user wants to have a different module name, an additional argument MODULE_INTERFACE_NAME of the qt_internal_add_module function is introduced. This also changes the way how target dependencies are collected and resolved. Since the 'Private' suffix no longer means an unique identifier of the module 'Private' part, we look for the both Private and non-Private package names when resolving dependencies. TODO: This change doesn't affect the existing internal modules, so to keep compatibility with the existing code the existing internal modules create 'Private' aliases. The code that provides backward compatibility must be removed once all internal modules will get the proper names. Taks-number: QTBUG-87775 Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add support for building and installing repo target setsJoerg Bornemann2021-05-204-0/+57
| | | | | | | | | | | | | | | | | | | | | | | 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: Introduce finalizer mode handling of static pluginsAlexandru Croitor2021-05-202-3/+187
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow linking all plugin initializer object libraries directly into the final target (executable or shared library). The finalizer mode is triggered when the project adds a call to qt_import_plugins, as well when the project has an explicit call to qt_finalize_executable or when it is defer called by CMake 3.19+. Otherwise the old non-finalizer mode is used, where each plugin initializer object library is propagated via the usage requirements of its associated module. A user can explicitly opt in or out of the new mode by calling qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE) The implementation, at configure time, recursively collects all dependencies of the target to extract a list of used Qt modules. From each module we extract its list of associated plugins and their genex conditions. These genexes are used to conditionally link the plugins and the initializers. Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the property even on INTERFACE libraries with lower CMake versions. QT_PLUGINS is kept for backwards compatibility with projects already using it, but should be removed in Qt 7. The upside of the finalizer mode is that it avoids creating link cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to duplicate the library on the link line, slowing down link time as well as possibly breaking link order dependencies. The downside is that finalizer mode can't cope with generator expressions at the moment. So if a Qt module target is wrapped in a generator expression, it's plugins will not be detected and thus linked. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Build plugin initializers as object libsAlexandru Croitor2021-05-184-45/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of compiling the plugin initializers as part of a user project, pre-compile them as object libraries while building Qt. The installed object libraries can then be used with target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) so that they are linked into the final executable or shared library via qt module usage requirement propagation. This reduces the build times of user projects. The link line placement of the object files should be correct for all linux-y linkers because the only dependency for the object files is Core and the Gui -> plugin -> Gui -> Core cycle does not hamper that from empirical observations. As a consequence of the recent change not to link plugin initialization object files into static libraries, as well not having to compile the files in user projects, we can get rid of the _qt_internal_disable_static_default_plugins calls in various places. A side note. Consider a user static library (L) that links to a Qt static library (Gui) which provides plugins (platform plugins). If there is an executable (E) that links to (L), with no direct dependency to any other Qt module and the intention is that the executable will automatically get the platform plugin linked, then (L) needs to link PUBLIC-ly to (Gui) so that the plugin usage requirements are propagated successfully. This is a limitation of using target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which will propagate object files across static libraries only if qt_module is linked publicly. One could try to use target_link_libraries(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>) which preserves the linker arguments across static libs even if qt_module is linked privately, but unfortunately CMake will lose dependency information on Core, which means the object files might be placed in the wrong place on the link line. As far as I know this is a limitation of CMake that can't be worked around at the moment. Note this behavior was present before this change as well. Task-number: QTBUG-80863 Task-number: QTBUG-92933 Change-Id: Ia99e8aa3d32d6197cacd6162515ac808f2c6c53f Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* cmake: Add repository name to test labels for qt5 buildsTor Arne Vestbø2021-05-181-1/+7
| | | | | Change-Id: Icb23f2ea885f6d21bef80c587a431f7e9349f21b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Provide supported qt_internal_add_module() args via a functionCraig Scott2021-05-181-6/+46
| | | | | | | | | | This is to allow other repos like qtdeclarative to more easily pass through supported arguments to qt_internal_add_module() from their own functions. Task-number: QTBUG-88763 Change-Id: I965d593de4c6f9d5295a0d427c32dc3d5b1bb639 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Don't do plugin initialization for static librariesAlexandru Croitor2021-05-171-0/+7
| | | | | | | | | | | | | | | | | | | | Q_IMPORT_PLUGIN generates a global static symbol that initializes a plugin. If this symbol is added to a static library and the library is then linked to an executable, the linker decides that the symbol is unused (because nothing references it) and discards it. This means there's no point to compile the Q_IMPORT_PLUGIN containing files into static libraries. Change the generator expression we use for plugin propagation via associated modules to not compile and link the plugin initialization object file into a static library. Pick-to: 6.1 Task-number: QTBUG-80863 Change-Id: Ide32c0124c1e313c352a72280ce32ce9fbe8fff1 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* wasm: make sure bind is compiler argumentLorn Potter2021-05-141-0/+1
| | | | | | Fixes: QTBUG-93713 Change-Id: I027caccb5c37bab529c80efac0b575a363be5f89 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: add an option to enable or disable versioned hard linkLi Xinwei2021-05-132-0/+8
| | | | | | | | | | | 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>
* Fix typo in FindWrapAtomic.cmakeJohn Zimmermann2021-05-121-3/+3
| | | | | | | | There was a D missing, we want to set CMAKE_REQUIRED_LIBRARIES Pick-to: 6.1 Change-Id: I7a76d60480ef7bff439f298fe85614d3b7e3ae88 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Add 'collect_targets' mode to __qt_internal_walk_libsAlexandru Croitor2021-05-111-13/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | Allow collecting all public dependency CMake targets starting from a given initial target. The new mode walks INTERFACE_LINK_LIBRARIES of a shared library or executable target, as well as the INTERFACE_LINK_LIBRARIES and LINK_LIBRARIES of a static library target. Each encountered target (checked with if(TARGET)) is added the output list. Note that the private dependencies of a non-static target (like a shared library or executable) are not walked by the new mode. Introduce a new function called __qt_internal_collect_all_target_dependencies which uses the new mode to collect the full private dependency list of a target. The final list only contains targets, so no linker flags or file paths. This list is useful to do further processing on the targets like extracting properties from them and running finalizers. Task-number: QTBUG-92933 Change-Id: I5d96cfa05722d65e2248a344a4f2b0f98a992817 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Make qt_internal_walk_libs available in public projectsAlexandru Croitor2021-05-1110-260/+267
| | | | | | | | | | | | | | | | | | 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: Hide qt plugin static import source files in a dot folderAlexandru Croitor2021-05-111-1/+1
| | | | | | | | | To keep the build directory tidier. Task-number: QTBUG-92933 Change-Id: I27213185a78b292bda7ae34bbc8161d4b5583872 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* CMake: Refactor handling of static pluginsAlexandru Croitor2021-05-116-116/+203
| | | | | | | | | | | | | | | | | | | | Extract common static plugin handling functionality into a separate QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package. Split the code into smaller functions that will be re-used by each templated QtPlugins.cmake.in file, rather than copy pasting the same code into each QtFooPlugins.cmake file. As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake as public helper files just like QtPublicPluginHelpers.cmake. This makes it clearer that the functions are available outside the internal Qt build and also provides a way for not dumping new helper functions into Qt6CoreMacros.cmake. Task-number: QTBUG-92933 Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: use additional search paths also for tool packageSamuli Piippo2021-05-101-1/+5
| | | | | | | | | | Use paths configured with QT_ADDITIONAL_PACKAGES_PREFIX_PATH to search also for the tool packages. Task-number: QTBUG-93565 Pick-to: 6.1 Change-Id: I611b275dd7c4e7ecceb073d16643cd225bbb21d8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Split qt_repo_build() into reusable macrosAlexandru Croitor2021-05-101-2/+21
| | | | | | | | | | Sometimes projects don't follow the standard directory layout, so they end up copy-pasting the guts of qt_build_repo and adapting that. Split the macro into smaller ones so it's easier to reuse. Change-Id: I8cc72ba2a2eaf58afd44950b3ac78378b7b1fdfd Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't use list(PREPEND) in qt.toolchain.cmakeAlexandru Croitor2021-05-101-2/+3
| | | | | | | | | | | | | | | | | list(PREPEND) command was added in CMake 3.15+, but so far we claim support for CMake 3.14 in user projects. Use set command instead. This is not the only place where we use list PREPEND in public API, but it's the first immediate issue that comes up when using CMake 3.14. Amends 963017f58884dfd929249c5546aadbb0f74501e8 Pick-to: 6.1 Change-Id: I7ba4507fc7da2dc550317848751502b8b46c298c Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Don't build cmake build tests as macOS universalAlexandru Croitor2021-05-101-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | We want standalone tests added by qt_internal_add_test to be built as universal executables, so we can build them on an intel machine and run them on an ARM machine. But CMake build tests will be built on the final machine that runs the tests and it might lack a universal SDK. That's why they should be built only targeting the architecture of the machine they're running on. Change the generated qt.tooclhain.cmake file to allow opting in or out of building projects with the same architectures as Qt was configured with. Now standalone tests will be multi-arch, but CMake build tests will be single-arch. Amends e379147f9571af8c3af5768b9040e0180819a855 Task-number: QTBUG-85447 Task-number: QTBUG-87580 Task-number: QTBUG-92933 Change-Id: I41ab047983115f84eb2333cc9ac2d19ca08d621f Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Fix developer buildJoerg Bornemann2021-05-101-0/+2
| | | | | | | | | The -developer-build had not the desired effect anymore. That argument must not be hidden from the feature logic. This amends commit d5c3e1336bc. Change-Id: I96562ea2df43ba7de002e705f28c7cc7edb4a589 Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Allow to load -developer-build without configurations into an IDEKai Köhne2021-05-071-0/+12
| | | | | | | | | | | | | | | Let -developer-build, -cmake-file-api set up the CMake File API query, so that the build can be loaded directly into IDE's like Qt Creator. [ChangeLog][Build System] configure -developer-build now sets up the CMake File API query, so that a build can be loaded without reconfiguration into Qt Creator and other IDE's. Pass -developer-build -no-cmake-file-api to configure to disable this. Fixes: QTBUG-89487 Change-Id: I69199b8f96da02e42e5610aa6f49881c1582f7da Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
* CMake: fix build with static BrotliLi Xinwei2021-05-071-0/+7
| | | | | | | | | | BrotliCommon is a dependency of BrotliDec and BrotliEnc. amends 5d2da76c1ee70ffd1f027365c0f3af74b76fd382 Pick-to: 6.1 Change-Id: I7741d417e95737f8caacd01962985a27dbb7514c Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add instructions for Windows 10 on Arm configSimo Fält2021-05-052-0/+16
| | | | | | | Task-number: QTQAINFRA-3966 Change-Id: Ib8ac80a5b8aa5c88d9e5d0eaad9ba550cc2442f8 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Fathi Boudra
* Add -write-options-for-conan configure argumentJoerg Bornemann2021-05-051-2/+78
| | | | | | | | | | | Passing this configure argument will generate a JSON file that contains information about configure options and features. This file is used by Qt's conan recipes. Fixes: QTBUG-92082 Change-Id: I2057ec8cbdb0a1ea198d7eeacb45f65bfa862d8a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Fix Windows build with CMake < 3.19Joerg Bornemann2021-05-051-2/+2
| | | | | | | | | | | | | | file(REAL_PATH) was introduced in CMake 3.19. Use get_file_name_component(... REALPATH) instead that is available in older CMake versions. This amends commit b226e99c71c. Pick-to: 6.1 Change-Id: Ibb28ef757228e1a1176ff70c3ec57b7ca751a636 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Add ABI suffix to .prl files for AndroidJoerg Bornemann2021-05-031-1/+5
| | | | | | | | | The libraries already contain the ABI suffix, and the .prl files should too. This is a requirement for ABI-stitching of Qt Android builds. Fixes: QTBUG-90023 Change-Id: Ib2a7b3119ace14c8542242fc45f42648840d053a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Update the comment in QtFinishPrlFile.cmakeJoerg Bornemann2021-05-031-2/+4
| | | | | | | | Clarify that OUT_FILE is not the final .prl anymore and where we get the path of the final .prl from. Change-Id: I4563c6ef1026bc0646e3ac9ab2fac49e426ca07f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: FreeBSD has DF_ORIGIN supportThiago Macieira2021-05-011-1/+1
| | | | | | Pick-to: 6.1 6.0 Change-Id: I755911ae7d0341f49039fffd167afce7fe6b2b38 Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
* Do not use qt_internal_module_info for non-module targetsAlexey Edelev2021-04-302-4/+10
| | | | | | | | | | | | The qt_internal_module_info function suppose to provide the information only about the Qt modules. Avoid using it for the tool and extra package dependencies, since some targets do not always exist, when function is called. Add the qt_internal_qtfy_target function to make the prefixed target names. Change-Id: Ifa8c61064d9c6c430889f00a4ead304029da711b Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix reconfiguration when using a static top-level buildAlexandru Croitor2021-04-291-2/+6
| | | | | | | | | | | | | | | | | | | | | | | ... and configuring another repo using qt-configure-module. It's possible to configure a top-level Qt with a subset of repos and then afterwards configure additional repos with qt-configure-module. We didn't define QT_REPO_DEPENDENCIES in that case, which caused all plugin config files to be loaded on reconfiguration, thus causing duplicate target errors. Move the QT_SUPERBUILD check to be done every time in QtBuildInternals.cmake rather than when configuring qtbase/qt5. Amends 98e8180e56322ce065e39cc1ef1d65b54caa8c25 Pick-to: 6.1 Fixes: QTBUG-86670 Fixes: QTBUG-91887 Fixes: QTBUG-92578 Change-Id: I975835ffa02f702799a3c9f68a5e059d2763a951 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Make a documentation-only build possibleJoerg Bornemann2021-04-291-8/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | Packagers usually build Qt per repo, but the documentation must be built from the full Qt source archive to ensure that inter-repo links are set up correctly. When building the documentation, it's desirable to avoid building tools and re-use to tools of an existing Qt build. One now can do a documentation-only build by configuring Qt like this: cmake /path/to/Qt/source -GNinja \ -DQT_HOST_PATH=/path/to/Qt/installation and build the documentation with ninja docs To avoid building tools, this patch removes the DEPENDS arguments from some add_custom_target calls in QtDocsHelpers.cmake and makes another one conditional. The removed dependencies are added at the end of qt_internal_add_docs. Adding of tool dependencies is not done if QT_HOST_PATH is set. Fixes: QTBUG-88441 Change-Id: I3b7a908e22d252d2edcdc1dd522a78b8ad6c487e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add versioned alias for the Platform targetAlexey Edelev2021-04-271-0/+1
| | | | | | | | | It's necessary to have versioned alias of the Platform target to use versioned target in the installable cmake files. Pick-to: 6.1 Change-Id: I79286e1c0642068bdfa5d24c1087ee0c39e48f1a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* wasm: do not set autodetect wasm true until we actually detectLorn Potter2021-04-271-1/+1
| | | | | Change-Id: Ib6bdd3d5ed7dab108b636284ee564d14dbc2d5c8 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Inhibit CMake generator detection for qt-configure-moduleJoerg Bornemann2021-04-261-1/+2
| | | | | | | | | | | | | | When configuring a Qt module with qt-configure-module, we want to use the same CMake generator that was used for building qtbase. That generator is encoded in qt-cmake-private. But qt-configure-module overrides the generator after trying to detect what generator should be used. That auto-detection is only useful for qtbase-builds and top-level builds. Turn it off for repo builds other than qtbase. Pick-to: 6.1 Fixes: QTBUG-91405 Change-Id: I07efb4afb51ba69d2f5467d272118fa51637ab54 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make qt-internal-configure-tests relocatableAlexandru Croitor2021-04-262-14/+21
| | | | | | | | | It's important for conan CI builds where the correct installation location of Qt should be used when configuring standalone tests. Task-number: QTBUG-93037 Change-Id: I2465a439aea6826dedfb3217d1c909ad639d4ac0 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Install prl files from all repo build dirs in a top-level buildAlexandru Croitor2021-04-261-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, in a top-level build we always generated the final prl file somewhere under QT_BUILD_DIR (which is qtbase_build_dir). After each repo was processed by QtPostProcess.cmake, we installed the prl files found in PROJECT_BINARY_DIR. For qtquickcontrols2 this meant that qml plugin prl files were placed under qtbase/qml, but we tried installing the prl files from qtquickcontrols2/qml, which didn't have any prl files. In a static Qt build, qmake's qt.prf calls qmlimportscanner to identify which plugins should be linked to the executable. This worked fine because the plugin .pri files were installed correctly. None of the qml plugin library dependencies were linked in though. This is supposed to happen in qmake's C++ code where it tries to find the associated prl file of a linked library in order to extract all its dependencies. Because no prl file was found, linking failed with multiple undefined symbols. Fix this by installing the prl files from QT_BUILD_DIR rather than PROJECT_BINARY_DIR. Note that this will create multiple install rules for certain files, but it's harmless. An example is imageformats. We process qtbase plugins, see qjpeg, issue an install rule from under the qtbase/plugins/imageformats folder. We then process qtimageformats plugins, see webp, issue another install rule from under qtbase/plugins/imageformats. The first install rule will install both qjpeg and qwebp, the second install rule will merely say all plugins are up-to-date. Pick-to: 6.1 6.0 Change-Id: I8a4bb67bfafc1d016eab62f4fe66b6ba378ceeb2 Fixes: QTBUG-93021 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Error out if requesting Android build without toolchain fileJoerg Bornemann2021-04-231-0/+6
| | | | | | | | | | Passing Android-related variables to the initial CMake call would have no effect if no (or an empty) value of CMAKE_TOOLCHAIN_FILE was specified. To alleviate user confusion, yield an error if an Android build was apparantly requested, but the toolchain file is missing. Change-Id: I28ec94eabe436d4b9b410b48c7cad1b48d3e1bec Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Android: Choose latest version when autodetecting the NDKJoerg Bornemann2021-04-231-2/+21
| | | | | | | | | | | | Before, we relied on the deprecated "ndk-bundle" subdirectory being present in the SDK root. Now, we choose the NDK with the latest version in the SDK's ndk subdirectory. Pick-to: 6.1 Fixes: QTBUG-87579 Change-Id: I37a9e03184f4518b4074d55375af08209591de94 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
* Android: Do not auto-detect NDK if ANDROID_NDK_ROOT is setJoerg Bornemann2021-04-231-1/+1
| | | | | | | | | | | | | When ANDROID_NDK_ROOT is explicitly set by the user, there's no point in detecting the NDK. The detection had no effect, because the already set ANDROID_NDK_ROOT variable would not be overwritten by our set call. Fix the condition of the check: There is no CMAKE_ANDROID_NDK_ROOT variable. Pick-to: 6.1 Change-Id: I8f0d4f2a1a67445f67a79c7d2d0932099828b05e Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Allow enabling Apple app extension API in other reposAlexandru Croitor2021-04-232-3/+4
| | | | | | | | | | | | | | It's needed in qtconnectivity, but currently the qt_disable_apple_app_extension_api_only function is defined in QtInternalTargets.cmake which is loaded only in qtbase. Move the function to cmake/QtTargetHelpers.cmake. Amends e189126f1ae1d2fa2ad0f95ee2c4aa72c770a97b Pick-to: 6.1 Change-Id: Ia2470e48a91385239394368780f5bbb223000113 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Lowercase system includes and lib names for Windows, fix cross compilingMartin Storsjö2021-04-231-1/+1
| | | | | | | | | | | | | | | When cross compiling from a case sensitive file system, casing matters, and mingw headers and import libraries consistently use lowercase. This was uncovered by d385158d5213ef568b7629e2aa4a818016bbffac; prior to that, the schannel TLS plugin didn't end up built (at least when cross compiling). Fix other similar cases that can be found by grepping the repo. Change-Id: Ia696e17b7aaa979d7b7f5b0801383f338a8b585b Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
* CMake: Allow usage of QtStandaloneTestTemplateProject as package componentCristian Adam2021-04-234-30/+46
| | | | | | | | | | | | | | | | | | | | | | | Currently in order to compile a Qt6 test standalone one needs to use the qt-cmake-standalone-test script which will load the Qt6BuildInternals/QtStandaloneTestTemplateProject/CMakeLists.txt project with the current test source directory to create a complete CMake project. This commit will allow a test to have these lines at top: cmake_minimum_required(VERSION 3.16) if (NOT QT_BUILD_STANDALONE_TESTS AND NOT QT_BUILDING_QT) project(a_qt_test LANGUAGES C CXX ASM) find_package(Qt6BuildInternals COMPONENTS STANDALONE_TEST) endif() and be standalone and work with any IDE capable of loading CMake projects. Fixes: QTCREATORBUG-25389 Pick-to: 6.1 Change-Id: If3f878b7e560a8bfbb604a8f1aa30b7962742e66 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix auto-linking of static plugins for non-QML in-tree testsAlexandru Croitor2021-04-222-16/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard build plugins associated with Qt modules from other repositories (qtsvg's QSvgPlugin associated to qtbase's QtGui). When configuring in-tree tests in the same build folder as the repository, the test executables would not automatically link to these plugins. Fix this by recording the existence of such plugins in a separate property of the associated Qt module and only link them when both the test executable and plugin are from the same project (their PROJECT_NAME coincides). This is in addition to linking the plugins associated with the module where both are built in the same repository. The logic is a bit tricky and ensures that plugins are not accidentally initialized twice, so that in-tree tests work for both top-level and per-repo builds. As a drive-by, added a TODO explaining why in-tree tests that need to link to static QML plugins won't work (somewhat unrelated to this change). Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add Solaris support in cmake buildNiclas Rosenvik2021-04-214-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* CMake: Fix auto-linking of static plugins in standalone testsAlexandru Croitor2021-04-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The change introduced in 98e8180e56322ce065e39cc1ef1d65b54caa8c25 fixes reconfiguration issues for repositories that provide plugins associated with modules from a different repository (QSvgPlugin -> QtGui -> qtbase). It does so by only loading the public Plugin CMake packages of dependent repositories. For executables / tests that are built as part of the current repository, plugins are linked via a different simplified mechanism in qt_add_internal_plugin and qt_internal_add_plugin in order to prevent exporting link cycles between plugins and Qt modules. This works for the majority of in-tree tests, but unfortunately breaks static standalone tests. For example in qtbase neither mechanism will link plugins to the standalone tests: - qtbase has no repo dependencies, so the first mechanism (loading of public plugin packages) is skipped because we assume we are merely reconfiguring the main build of qtbase and we don't want to accidentally create duplicate plugin targets - because a standalone test configuration does not call qt_internal_add_plugin, no association is done between qt plugin and module and thus all tests (qt_internal_add_test -> qt_internal_add_executable) don't get the simplified plugin linking Fix this by allowing loading of the public CMake plugin packages when doing standalone tests. It should be safe to do so because we don't build any plugins in this case, only tests. Amends 98e8180e56322ce065e39cc1ef1d65b54caa8c25 Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I690a0366c73a24e7f49c65ed13cd70362c273d81 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-09 17:44:17 +0000