summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* Fix top-level build repository targetsJoerg Bornemann2021-04-191-9/+10
| | | | | | | | | | | | The directory-level targets missed the first level of sub-targets. E.g. `qtbase_qmake` did not have a dependency to `qmake`. Fix qt_build_internals_get_repo_targets to first grab all targets of the subdirectory and then recurse. Pick-to: 6.1 6.0 Change-Id: I3604000caec22fac9a4cc5f5aaf651d550d16793 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Warn when using CMake 3.20.1 due to crashes in AUTOMOCAlexandru Croitor2021-04-171-0/+6
| | | | | | | | | | | | With CMake 3.20.1 AUTOMOC can crash or hang on Windows when used with a Qt installation that supports moc depfiles due to missing multi-threaded locking. Warn and advise to use a different CMake version instead. Change-Id: I78d2269c48dfc2541bebcd6ab23aaa5595012149 Pick-to: 6.1 6.0 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Switch metatypes generation on by default for Qt modulesUlf Hermann2021-04-161-9/+19
| | | | | | | | | | We need the metatypes for anything directly or indirectly exposed to QML. Switching this on has no runtime overhead. For interface libraries we cannot generate any metatypes, though. Change-Id: I7b7f85bb4e16c28d00383c5c88b0f1c172c8d193 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
* Merge integration refs/builds/qtci/dev/1618489823Qt CI Bot2021-04-152-1/+2
|\
| * CMake: Don't consider /opt/homebrew as a system path for arm64 macOSAlexandru Croitor2021-04-151-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Homebrew introduced a new default prefix for Apple Silicon machines, so that both arm64 and x86_64 packages can be co-installed on a single system. The intel packages are installed into /usr/local and the arm64 packages are installed into /opt/homebrew. For Qt building purposes, we don't want to find packages in any of homebrew's prefixes unless explicitly requested by the user Currently our arm64 macOS CI config does pick up system libs under new prefix. Remove the new path from the system prefixes. Amends f3c7d22dd04afe8d889585fb5d6426f3d4591e74 Task-number: QTBUG-85447 Change-Id: I381d31c95bcdab26147a331444ba40c7af9d0a95 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
| * CMake: Use PROJECT_VERSION for generated QtModule.json filesAlexandru Croitor2021-04-151-1/+1
| | | | | | | | | | | | | | | | So that the correct version is generated in top-level builds. Change-Id: I360370815ce178564cc79157dc61d70adfd4f947 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* | Check if all required Qt targets are declared when finalizing the moduleAlexey Edelev2021-04-151-0/+3
|/ | | | | | | | | | | | | | | | | | CMake makes possible to specify a target in the target_link_library call even if the target is not declared yet. This adds flexibility to the target declaration arrangement. For the Qt modules we have to restrict freedom, because of the .prl files generating. If the Qt module depends on another Qt module, the dependecy must be declared before the module finalizing step, otherwise this will cause invalid records in the module .prl file. TODO: The dependency order issue could be solved by using conditional genex's when generating step1 .prl file. But we ask developers to depend on Qt module targets that have been defined before their usage. Fixes: QTBUG-89467 Change-Id: I12ce1000048fd4a2f3334f17720c8df1c680ca20 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Fix hardcoded iOS SDK when finding OpenGLESAlexandru Croitor2021-04-151-2/+2
| | | | | | | | | | | | | | | | The find script checked for UIKIT which is set during a Qt build in QtPlaformSupport.cmake but is not set when building a user project. This casused the find script to skip the iOS specific code that passed the -framework OpenGLES linker flag. This broke SDK switching in Xcode. Check the IOS variable instead which is set by CMake for all projects that pass -DCMAKE_SYSTEM_NAME=iOS. Pick-to: 6.1 Change-Id: I9bd088f317917544ccfeff61fc4ff90f18f0f3d8 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Fix default architecture selection for macOS and iOSAlexandru Croitor2021-04-141-5/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this change, we created a CMake toolchain file for iOS and macOS universal which propagated the initially configured CMAKE_OSX_ARCHITECTURES values to user projects. So if Qt was configured with 2 arches, configuring a CMake user project using the generated toolchain file would also build the user project targeting those 2 arches. The reason for this that the same toolchain file is used for configuring both Qt and users projects and we needed to ensure that other Qt repos are built with the same set of arches. That unfortunately led the multiple arches to carry over into user projects. This is different from qmake behavior which configured user projects with 1 arch only. Instead of the toolchain file explicitly setting CMAKE_OSX_ARCHITECTURES for all projects, save the initial list of arches into QT_OSX_ARCHITECTURES. Then if the toolchain file detects that we're building a Qt repo (by checking for the presence of QT_REPO_MODULE_VERSION) set CMAKE_OSX_ARCHITECTURES to QT_OSX_ARCHITECTURES to propagate the initial list of arches. For user projects we want to have some sensible defaults. For macOS projects, leave the decision of the architecture to build to CMake. For iOS Xcode projects, leave the decision to Xcode. For iOS Ninja projects, set the architecture to the first value of the architectures used when configuring Qt. As a side note this fixes an issue in our CI where we configured macOS Qt with 2 architectures and then tried to run CMake build tests for both architectures on a machine that doesn't have the universal SDK. This led to build failures. Because the CMake build tests act as regular user projects, now they are configured with a single architecture that is automtically detected by CMake. Pick-to: 6.1 Task-number: QTBUG-85447 Change-Id: Id1b7e78d7e67c1796efed10751416e5f857c16d2 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* Add CoreMotion to the list of looked-up frameworks (Mac/iOS)Juha Vuolle2021-04-141-1/+1
| | | | | | | | The CoreMotion is required by the QtSensor module. Task-number: QTBUG-92502 Change-Id: I7f1853131aa96b2cb052862d5bf492df5ec18150 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Merge integration refs/builds/qtci/dev/1618224780Qt CI Bot2021-04-121-2/+2
|\
| * Use bracket-based escaping for all list arguments in a configure stringAlexey Edelev2021-04-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | The 'list(TRANSFORM cmake_args REPLACE "\\[\\[;\\]\\]" "\\\\;")' call breaks the list arguments added when evaluating the 'INPUT_' values. Therefore, it's necessary to apply bracket-based escaping to all list arguments instead of the standard escaping. Amends 856fadf85ca2a3b70878d01d32e4d4cef807b8a9 Fixes: QTBUG-92459 Change-Id: Ifd4e0ca5f549a1c7fab9ceb587ed355250c4e677 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* | CMake: Fix condition evaluation in plugin's DEFAULT_IF optionAlexandru Croitor2021-04-121-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | Expand the condition without an extra negation. This fixes incorrect condition evaluation for conditions not enclosed in parenthesis. Pick-to: 6.1 Change-Id: I4923059b6b199676058091c23d51c9368daaebd0 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* | CMake: Fix auto-importing of plugins in static Qt qmake projectsAlexandru Croitor2021-04-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously the plugin .pri files that CMake generated for qmake consumption contained an '-' to exclude the plugin from auto-importing only if the plugin type was generic or a platform plugin. Now that plugin projects that should be excluded have a proper DEFAULT_IF FALSE clause, we can simply query for the defaultness of the plugin to know whether to exclude it in the generated .pri file. This fixes an issue with Qt static builds and qtvirtualkeyboard. The vkb plugin was not excluded and thus any simple QtGui app linked to the vkb plugin in a static qmake project. This led to linker issues because the vkb plugin also depends on a vkb quick plugin which is not listed as a dependency. Augments 76230d98795a2e7a365328eb693ff57f6ddd7f1d Amends c975c35eaebcca3bd33931fecc3beb513e332292 Pick-to: 6.1 6.1.0 Fixes: QTBUG-92529 Task-number: QTBUG-87861 Change-Id: I9671f6504374cf0799289bbe19110e01c129402e Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* | CMake: Fix duplicate symbol errors in Windows static super buildsAlexandru Croitor2021-04-121-18/+21
|/ | | | | | | | | | | | | | | | | | | | | | | | | qt_internal_add_executable has some special logic to link static plugins in order to avoid issues with link cycles on exported Qt module targets. This logic does not take into account if a plugin is a default plugin. On windows this caused duplicate symbol linking issues in static super builds, because both qwindows and qdirect2d define a subset of the same symbols. Make sure to only link to default static plugins. This will skip linking to qdirect2d because it's not a default qpa plugin and thus avoid linker issues. Amends 5807e1ae8168a5702ad0f6890d2b35223cfebdee Pick-to: 6.1 6.1.0 Fixes: QTBUG-92451 Change-Id: I56df2ce0201625088417de53038642518c1d3bbd Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Warn if using CMake 3.20.0 due to potential cyclic dependenciesCraig Scott2021-04-121-0/+5
| | | | | | | | | | CMake 3.20.0 can create autogen-related cyclic dependencies that are only detected at build time by Ninja, which then fails with a build error. Warn and advise to use a different CMake version instead. Pick-to: 6.1 6.0 Change-Id: I9bef973ad2efdb69f28d6a9e0584b543be59f17f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Merge integration refs/builds/qtci/dev/1617891528Qt CI Bot2021-04-081-3/+7
|\
| * Skip adding externally added plugins to the plugin meta-setsAlexey Edelev2021-04-081-3/+7
| | | | | | | | | | | | | | | | Plugin meta-sets are not visible outside of the module build tree, so there is no point in adding dependencies for externally added plugins. Change-Id: Ica5b29b57c032f4fc9b128172aaa806392e9e581 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* | Merge integration refs/builds/qtci/dev/1617880670Qt CI Bot2021-04-081-2/+0
|\ \ | |/ |/|
| * Specify QT_TESTCASE_BUILDDIR for Qt::Test users implicitlyAlexey Edelev2021-04-081-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QT_TESTCASE_BUILDDIR was implicitly defined by Qt::Test target for library users in Qt5. By default, this definition will point to CMAKE_CURRENT_BINARY_DIR. This logic works similarly to qmake logic. From user's perspective it might be useful to not rely on standard search paths, but specify own. This can be done by setting the QT_TESTCASE_BUILDDIR property for the user's target. CMake will substute the value of the QT_TESTCASE_BUILDDIR property into the QT_TESTCASE_BUILDDIR definition. The implicit QT_TESTCASE_SOURCEDIR also seems to be useful. According to the current logic, it points to CMAKE_CURRENT_SOURCE_DIR. Fixes: QTBUG-92079 Change-Id: I8a9065f08e859c713b3c8cc08142a9ced0677770 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* | Fix linking order of the resource objectsAlexey Edelev2021-04-081-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | The generated object resource library depends on the Qt::Core library because uses the functions defined in qresource.cpp. Dummy linking of the Qt::Core to an object library has an effect only when the object library is linked directly to the executable as a target. If we link the object library as INTERFACE library we miss out all the objects that need to be linked to the executable. This behavior is explained here: https://bit.ly/3sFWKvI Thus, the only option to link the object library objects to the endpoint executable is to use TARGET_OBJECTS property in genex, as it's already done. But that means we are losing all profits that target actually has, especially linking the object library dependencies. The combination of both of the above methods does the job. The only thing that looks fragile so far is order. Currently, the order we use in the target_link_library call applies to the linker command line. This means the object library objects must always appear before the object library target. Change-Id: If1f0e35e0445d5e96a1f2249ab44114cd36630e9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Remove use of qt_internal_module_info from qt_internal_add_pluginAlexey Edelev2021-04-071-3/+1
| | | | | | | | | | | Plugin targets don't fit the requirements of the module but use the function associated to the module. The purpose of using qt_internal_module_info is to get the path to the top-level include directory. So there is no point in breaking the encapsulation rules to get a well-known directory. Change-Id: If3d2a31d4ec186929e3d662a79a1ae9eac988d1a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Build minimal subset of tests in desktop static buildsAlexandru Croitor2021-04-063-6/+9
| | | | | | | | | | | | | | | | | | | | | | | Add new configure option -make minimal-static-tests and CMake option QT_BUILD_MINIMAL_STATIC_TESTS. In conjunction with QT_BUILD_TESTS it will enable building a minimal subset of tests when targeting a static desktop Qt build. In qtbase the minimal subset includes all the auto tests of testlib, tools, corelib and cmake. In particular this will also do cmake build tests and qmake build tests (tst_qmake) Adjust CI instructions to enable building a minimal subset of static tests when a platform configuration is tagged with the MinimalStaticTests feature. Fix and skip a few tests that were failing. Pick-to: 6.1 Task-number: QTBUG-87580 Task-number: QTBUG-91869 Change-Id: I1fc311b8d5e743ccf05047fb9a7fdb813a645206 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* CMake: Fix building multi-arch universal macOS QtAlexandru Croitor2021-04-017-9/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the same approach we use for iOS, which is to set multiple CMAKE_OSX_ARCHITECTURES values and let the clang front end deal with lipo-ing the final libraries. For now, Qt can be configured to build universal macOS libraries by passing 2 architectures to CMake, either via: -DCMAKE_OSX_ARCHITECTURES="x86_64;arm64" or -DCMAKE_OSX_ARCHITECTURES="arm64;x86_64" Currently we recommend specifying the intel x86_64 arch as the first one, to get an intel slice configuration that is comparable to a non-universal intel build. Specifying the arm64 slice first could pessimize optimizations and reduce the feature set for the intel slice due to the limitation that we run configure tests only once. The first specified architecture is the one used to do all the configure tests. It 'mostly' defines the common feature set of both architecture slices, with the excepion of some special handling for sse2 and neon instructions. In the future we might want to run at least the Qt architecture config test for all specified architectures, so that we can extract all the supported sub-arches and instruction sets in a reliable way. For now, we use the same sse2 hack as for iOS simulator_and_device builds, otherwise QtGui fails to link due to missing qt_memfill32_sse2 and other symbols. The hack is somewhat augmented to ensure that reconfiguration still succeeds (same issue happened with iOS). Previously the sse2 feature condition was broken due to force setting the feature to be ON. Now the condition also checks for a special QT_FORCE_FEATURE_sse2 variable which we set internally. Note that we shouldn't build for arm64e, because the binaries get killed when running on AS with the following message: kernel: exec_mach_imgact: not running binary built against preview arm64e ABI. Aslo, by default, we disable the arm64 slice for qt sql plugins, mostly because the CI provisioned sql libraries that we depend on only contain x86_64 slices, and trying to build the sql plugins for both slices will fail with linker errors. This behavior can be disabled for all targets marked by qt_internal_force_macos_intel_arch, by setting the QT_FORCE_MACOS_ALL_ARCHES CMake option to ON. To disble it per-target one can set QT_FORCE_MACOS_ALL_ARCHES_${target} to ON. Task-number: QTBUG-85447 Change-Id: Iccb5dfcc1a21a8a8292bd3817df0ea46c3445f75 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: Teach qt_internal_add_simd to exclude given osx architecturesAlexandru Croitor2021-04-011-9/+29
| | | | | | | | | | | | | | | | | | | | | | | | qt_internal_add_simd can now take an EXCLUDE_OSX_ARCHITECTURES list of values which specifies for which architectures the simd compile flags should not be added. This is relevant for macOS universal builds. Example CMAKE_OSX_ARCHITECTURES is "x86_64;arm64" EXCLUDE_OSX_ARCHITECTURES is "arm64" SIMD is avx2 the final compiler flags that will be added are "-Xarch_x86_64 -mavx2" Slightly, clean up the function implementation and document its arguments. NAME handling has been removed because it's dead code that hasn't been removed as part of 1b7008a3d784f3f266368f824cb43d473a301ba1. Task-number: QTBUG-85447 Change-Id: I395c19bdd67219bebb6b5b8d9f418b6e6488e09b Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* wasm: add cmake build supportLorn Potter2021-04-0113-10/+179
| | | | | | | | | | | | | | | | A few configure defines get changed: QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1 To create source maps for debugging. use device-option QT_WASM_SOURCE_MAP=1 Task-number: QTBUG-78647 Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Make architecture detection failures more verboseAlexandru Croitor2021-03-311-3/+21
| | | | | | | | | | | | | Whenever something went wrong with building the arch test or extracting info from it, the failure messages lacked useful details. It's especially hard to figure out what went wrong if the failure happened in the CI. Print a bunch of useful information in case of failure. Change-Id: Iafe287f951880c1441e57924ae372d6a9029a9a7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
* Fix DESTDIR support on Windows for versioned hard-linksJoerg Bornemann2021-03-311-4/+16
| | | | | | | | | | | | On Windows, we need to strip drive letter and colon before prepending DESTDIR when creating our versioned hard links. This fixes CI submodule updates. Change-Id: I41bc5f27b714ef74d3fadc4a0fb16c3d8b20da1a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit 88886f193230292f38987ac4f1503753f50786f0) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Make find_package in configure.cmake a hard errorJoerg Bornemann2021-03-311-0/+5
| | | | | | | | | | | | | | | qt3d/9a473a3c9b246f4895ae73d7060745b8b199a6c5 introduced a find_package call in a configure.cmake file, very subtly breaking top-level builds with configure. The find_package call results in errors of the cmake call that runs QtProcessConfigureArgs.cmake (see bug report for details). Create a find_package stub that errors out with a helpful message. Task-number: QTBUG-92163 Change-Id: I06db0bf219b965e93b78c690e9f7ad868196ddb9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Avoid using prohibited target property names with INTERFACE targetsCraig Scott2021-03-312-5/+5
| | | | | | | | | | | | | | | | | | | | CMake 3.19 removed the restrictions on allowable names for properties on INTERFACE targets. With earlier CMake versions (back to CMake 3.11), names for custom properties must begin with either a lowercase letter or an underscore. In 5807e1ae81 (Add plugins to Qt tools and executables for static builds, 2021-03-19), the names QT_REPO_PLUGIN_CLASS_NAMES and QT_REPO_PLUGINS were used, but in some cases, the targets on which they were being set are INTERFACE targets. Replace these with names that are supported with CMake 3.11 or later. Amends 5807e1ae8168a5702ad0f6890d2b35223cfebdee Task-number: QTBUG-91915 Pick-to: 6.1 Change-Id: Ife702a1fb339b190d46a8dafb380253219199ba6 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* CMake: Semi-handle non-current repo qt modules when creating pluginsAlexandru Croitor2021-03-311-12/+32
| | | | | | | | | | | | | | | | | | | | | | | | In the recent refactoring of qt_internal_add_plugin, a new target existence check was added when associating a plugin with a qt module. That check didn't account for a qualified qt module target name. This failed configuration of qtsvg which checked for the existence of a namespace-less 'Gui' in a per-repo build. Make sure to prepend the Qt namespace to the qt module name and also handle aliased target names. As a drive-by, add a TODO item to figure out how to link executables to plugins who's plugin type belong to a different repo, but both the executable and plugin are built in the current repo. Amends aa4a1006cbccbc180c600f9b4dc9e882bb5ed5ca Fixes: QTBUG-92235 Change-Id: I1c0f83672ab00f4702be9bad9a66ccc35e82f5c8 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> (cherry picked from commit 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* Merge integration refs/builds/qtci/dev/1617112958Qt CI Bot2021-03-301-4/+4
|\
| * Move bin/qt-internal-configure-tests to libexecJoerg Bornemann2021-03-301-4/+4
| | | | | | | | | | | | | | | | Pick-to: 6.1 Task-number: QTBUG-88791 Change-Id: I78613128760b5820e6db17b0c09462e34f7c7bb2 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* | Fix processing of list arguments passed to the 'configure' scriptAlexey Edelev2021-03-301-3/+11
|/ | | | | | | | | | | | | | | | list(TRANSFORM ...) unexpectedly removes semicolon escaping in list items. So the list arguments seems to be broken. The 'bracket argument' suppresses this behavior. Right before forwarding command line arguments to the cmake call, 'bracket arguments'are replaced by escaped semicolons back. Recent fix escapes all semicolons of the 'configure_args' and glues all arguments to a single 'list'. Amends df8e1c8e588cb0529b2bc02faef1022ef3f29145 Change-Id: I4a458b9e3add307b36924c4c7c7f739d348f9343 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>
* Fix plugin SKIP_INSTALL optionAlexey Edelev2021-03-291-5/+14
| | | | | | | | | | If SKIP_INSTALL option is specified for the qt_internal_add_plugin function the install_directory variable become empty and finalizer unable to call qt_finalize_plugin, because of lack of the second argument. It makes sense to use the INSTALL_PATH single argument instead. Change-Id: I2d4b40c8cf812a834c0e045569b45a649d339508 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Refactor qt_internal_add_plugin() and qt6_add_plugin()Craig Scott2021-03-295-113/+104
| | | | | | | | | | | | | | | | | | | | | | 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>
* Fix error when re-configuring an already installed Qt repositoryJoerg Bornemann2021-03-264-4/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building and installing a Qt repo that provides plugins for a Qt module within a different repository (for example, qtimageformats providing imageformat plugins for QtGui), re-configuring that repository would result in configuration errors like "add_library cannot create ALIAS target "Qt6::QTgaPlugin" because another target with the same name already exists." This happened, because the find_package(Qt6 COMPONENTS Gui) calls pulled in the Qt6*PluginConfig.cmake files that create imported targets for the plugins we want to build. To fix this, when building Qt, we now load only plugins that are provided by repositories the currently building repository depends on. We read the repo dependencies from dependencies.yaml when the Qt6BuildInternals package is loaded, but only in static builds and only if we're currently building a Qt repository. To find out whether we're building a Qt repository, we check whether QT_REPO_MODULE_VERSION is defined. We cannot check QT_BUILDING_QT, because that variable is not available for the first find_package calls in the repository's top-level project file. In each Qt6*PluginConfig.cmake file, we bail out if the plugin's repository is not one of the ones in QT_REPO_DEPENDENCIES. Fixes: QTBUG-86670 Fixes: QTBUG-91887 Change-Id: I8f6c8398032227032742f1ca019e983ff2bcd745 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Merge integration refs/builds/qtci/dev/1616686367Qt CI Bot2021-03-254-3/+68
|\
| * Add a way to install versioned hard-links for toolsJoerg Bornemann2021-03-254-3/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add the option argument INSTALL_VERSIONED_LINK to qt_internal_add_tool and qt_internal_add_app. For tools/apps with this argument we create an install rule that creates a versioned hard link. For example, for bin/qmake we create bin/qmake6. Note that this only applies to prefix builds. Apply this argument to qmake. The qt_internal_add_app change is necessary for qtdiag and in qttools. Task-number: QTBUG-89170 Change-Id: Id32d6055544c475166f4d854aaeb6292fbb5fbb5 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> (cherry picked from commit c19d957f45fa27f61b5ecc566f8dbc19f12a44c3)
* | CMake: Fix qconfig.cpp embedded prefix in the CIAlexandru Croitor2021-03-251-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the CI on a windows we configure Qt with the following prefix -DCMAKE_INSTALL_PREFIX:PATH=\Users\qt\work\install Note the lack of the drive letter. This is intentional, so that we can abuse CMake's DESTDIR installation mechanism to install into a custom path. This causes trouble for static Qt builds in the CI. Specifically when there is no qt.conf file next to qmake, qmake -query will report a QT_INSTALL_PREFIX:/Users/qt/work/install and ultimately qmake will fail to locate the module .pri files in such a path, showing errors like: Project ERROR: Unknown module(s) in QT: core gui? If a qt.conf is placed next to qmake (even an empty one), a differenct code path is used in qmake to resolve the prefix, which returns a path with a drive letter. In a shared build, because the 'relocatable' feature is enabled by default, a different code path is used and thus the prefix is also successfully resolved. So the problem is specific to static Windows Qt builds that have no qt.conf file next to qmake. This is the exact scenario that we encounter when running static Qt tests (tst_qmake in particular). To circumvent the issue, prepend a drive letter to the prefix hardcoded into qconfig.cpp. Do that with get_filename_component(REALPATH) which apparently resolves to a fully qualified path. Pick-to: 6.1 Task-number: QTBUG-87580 Change-Id: I17c885f29bfdee45bec1d6aac7c3b26723e761a3 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* | CMake: Remove some dead codeAlexandru Croitor2021-03-251-2/+0
|/ | | | | | | | | | The code was added as part of a6ccef651ddc075cf205bbd2693a26c08de6817a but the important bits were removed as part of c431e2d33c2b13dee8b43a08c267c20ec1ae9654 Change-Id: I6ba7bffa2bfdbeae2c92cd9ffeaa5f31771eedde Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* cmake: Handle arbitrary configure arguments that contain listsTor Arne Vestbø2021-03-231-2/+4
| | | | | | | | | Passing e.g. -- -DQT_BUILD_SUBMODULES="qtbase;qtdeclarative" to configure would fail because the module list was not preserved as a single argument. Change-Id: If685d0d541201597a2c2a5dc3d55b5d1ae51da22 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add plugins to Qt tools and executables for static buildsCraig Scott2021-03-235-33/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In static builds, we cannot allow any part of the main build to make a call to find_package(Qt6...) where such a call may load a Qt6*Plugins.cmake file. That would add additional dependencies to the main module targets, setting up a circular dependency in the set of *Config.cmake files which cannot be resolved. This scenario would be triggered by per-repo builds or user projects. But Qt's tools and other executables still need to load some plugins in static builds. Sometimes a platform plugin may be enough, other times we may want all supportable plugins (e.g. Qt Designer). Therefore, add all plugins we can identify as relevant for an executable that is part of the Qt build, but add them directly to the executable without affecting the linking relationships between the main module libraries. Also remove the now unnecessary check for QT_BUILD_PROJECT_NAME in top level builds because there should be no difference between per-repo and top level builds any more (as far as linking static plugins is concerned). Examples that build as part of the main build will still build successfully after this change, but they will not run if they require a platform plugin. Examples need to be moved out to a separate build where they can call find_package(Qt6) without QT_NO_CREATE_TARGETS set to TRUE to be runnable (see QTBUG-90820). Fixes: QTBUG-91915 Pick-to: 6.1 Change-Id: I8088baddb54e394ca111b103313596d6743570ba Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Fix backtrace on non-linux systemsNiclas Rosenvik2021-03-221-0/+17
| | | | | | | | | | | | On BSD systems backtrace lies in libexecinfo. Use FindBacktrace from CMake to be able to resolve backtrace on more unixes than linux. Change-Id: Ie14fd1727d2da03645fc2d6de10c0217baabad6b Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io> Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Remove unnecessary $<BOOL:...> generator expressionCraig Scott2021-03-221-4/+1
| | | | | | | | | The $<NOT:...> genex already guarantees to return a value of 0 or 1, so there's no need to wrap it with $<BOOL:...>. Pick-to: 6.0 6.1 Change-Id: Iff4ad64ed8deaa846e1b5bc22d2e5d9dbcd77cc7 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Properly set ICC and QCCNiclas Rosenvik2021-03-191-2/+2
| | | | | | | | | | | | | | | | | | Using CMAKE_C_COMPILER to match the compiler has its drawbacks. CMAKE_C_COMPILER can include the whole path to the compiler and directory names that incude icc, icl or qcc also match even if the compiler is not icc or qcc. Icc has the compiler id Intel according to the CMake documentation. The compiler id for qcc is QCC according to CMake policy 0047, and this is set to new since Qt requires CMake to be above 3.0. Change-Id: Iceb428ed10f0f5bbaa19ec2d883da186c85e7a73 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: James McDonnell <jmcdonnell@blackberry.com> 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>
* CMake: Make Platform a dependency for all Qt internal targetsAlexandru Croitor2021-03-192-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | In particular that influences BundledLibrary targets. Most internal targets already depended transitively on Qt::Platform via Qt::Core as a public dependency. This was not the case for BundledLibrary targets which don't link to Qt::Core. This led to compilation issues in user projects when targeting WebAssembly, due to mismatched flags between a bundled Harfbuzz vs a user project. Probably other subtle issues as well (e.g. none of the Windows specific compile definitions were passed to bundled libs). Bundled libraries depend on PlatformCommonInternal already, so make PlatformCommonInternal turn depend on the public Platform target. I thought that was already the case, but we merely relied on the Qt::Core dependency. Note that Qt::Core should still list Platform as a public dependency, so it gets propagated to user projects. Amends acf9b3a68b98b806329dd92184e632e049441cec Change-Id: Ida3b219818f89ec6eba2c2d92c5db65ad56bc5a4 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Prevent static plugin triggering autogen dependency on reconfigureCraig Scott2021-03-181-7/+15
| | | | | | | | | | | | | | | | | | | | A call to file(WRITE) will unconditionally update the file's timestamp even if the file's contents don't change. The *Plugin.cpp file was being written using configure_file() which avoids that, but the .cpp.in file it was configuring from was being written out using file(WRITE) every time CMake ran. Autogen saw that file as a dependency and then regenerated the mocs_compilation.cpp file, which in turn results in unnecessary rebuilds and relinking when nothing is actually changing. The file(WRITE) - configure_file() dance is no longer needed anyway, since the generated *Plugin.cpp file is very simple with no substitutions required. Therefore, we can simplify that file's generation with a single file(WRITE) that only executes if the file contents will change or the file is missing. Pick-to: 6.1 6.0 Change-Id: I2b7d1ff678b85ea7811969d656555592c9b6865f Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-26 22:23:11 +0000