summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
...
* | 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>
* CMake: Don't attempt to add to a target that doesn't existMårten Nordheim2021-03-171-2/+4
| | | | | | | | | | When configuring a benchmark using the standalone-test script the 'benchmark' target is not available, causing a configure error. Pick-to: 6.1 6.0 Change-Id: I8e480c9e72b47783c0910428187f0092049e89db Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Merge "Fix installation of Find*.cmake files in shadow per-repo builds"Joerg Bornemann2021-03-171-1/+1
|\
| * Fix installation of Find*.cmake files in shadow per-repo buildsJoerg Bornemann2021-03-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | In shadow per-repo builds we never hit the code that is supposed to install cmake/Find*.cmake files. This caused problems when statically building a Qt repo like qtshadertools against qtimageformats which provides such Find*.cmake files. Fixes: QTBUG-91538 Change-Id: I1147daee817ac71303d93e8bf368b2769afb0bb4 Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* | Fix configure build due to use of qt_set01 in configure.cmakeNiclas Rosenvik2021-03-171-0/+1
|/ | | | | | | | | | | The change "Enable X11 on other platforms than just Linux" uses qt_set01 in a configure.cmake file but does not add it to the stubs list in QtProcessConfigureArgs.cmake thus breaking builds based on configure. Add a defstub with qt_set01 to fix this. Change-Id: Ia3e0ec61df5228f88f77f631968f6f96d567ec8e Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* CMake: make sure to collect Android dependencies for pluginsAssam Boudjelthia2021-03-173-42/+67
| | | | | | | | | | | | androiddeployqt relies on *-android-dependencies.xml files to know what dependencies like jar files and permissions a Qt module requires. CMake create those files under Qt prefix's lib dir but CMake was not accounting for module plugins. Fixes: QTBUG-90812 Pick-to: 6.1 6.0 Change-Id: Ib3b2e2bb237159b4851ac0f23dc75f8e56af3f7a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Merge "Remove superfluous variable assignments from configure.bat"Joerg Bornemann2021-03-111-3/+1
|\
| * Remove the -qmake and -cmake configure argumentsJoerg Bornemann2021-03-111-3/+1
| | | | | | | | | | | | | | | | | | | | Qt is built with CMake since 6.0 and the QMake build system was removed in 6.1. It's time to remove the -cmake and -qmake configure arguments for Qt 6.2. Fixes: QTBUG-88286 Change-Id: Ie726ec364ded025f8d93bd69b469561a6ae40aa9 Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* | Merge "Fix CMAKE_INSTALL_PREFIX when building against installer-provided Qt"Joerg Bornemann2021-03-111-1/+1
|\ \ | |/ |/|
| * Fix CMAKE_INSTALL_PREFIX when building against installer-provided QtJoerg Bornemann2021-03-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building a module against an installer-provided Qt, CMAKE_INSTALL_PREFIX would default to /home/qt/work/install, which is the install prefix of our packaging machines. Do not hard-code the install prefix in QtBuildInternalsExtra.cmake but use the one that is calculated from the location of QtBuildInternalsExtra.cmake. Pick-to: 6.1 Fixes: QTBUG-90449 Fixes: QTBUG-91475 Change-Id: I39f214efb18796a89f00a171ef190c547bba5c0a Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* | Fix build of QTuioTouchPlugin with Makefile generator on macOSJoerg Bornemann2021-03-111-2/+8
|/ | | | | | | | | | | | | | | | | For each plugin, we create a custom target with it's OUTPUT_NAME such that one simply can do 'ninja qtuiotouchplugin' to build it. QTuiTouchPlugin has qtuiotouchplugin as OUTPUT_NAME, which is problematic with Makefile generators on case-insensitive file systems. See CMake upstream issue #21915 for details. Work around this issue by not creating the custom target in this situation. Pick-to: 6.1 Fixes: QTBUG-84342 Change-Id: Id9a6cf0a01c179d5c93da4146e393cf00153ac4f Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Merge "Remove now unneeded QT_BOOTSTRAPPED check from qlibraryinfo.cpp"Joerg Bornemann2021-03-111-17/+0
|\
| * Remove all qmake-related data from q[make]config.cppJoerg Bornemann2021-03-111-13/+0
| | | | | | | | | | | | | | | | | | | | | | | | Now that we're not actually using qmakeconfig.cpp anymore, we can remove it together with all qmake-related information that was written into qconfig.cpp. This also moves the qtConfEntries array back to qlibraryinfo.cpp. Change-Id: I5e57d8c55613332cc3e57b11df4398d46aed259b Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
| * Pass target and host mkspec as defines to QMakeLibraryInfoJoerg Bornemann2021-03-111-2/+0
| | | | | | | | | | | | Change-Id: If07055286496c507310c0dbb3a06f1a42d643596 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-07 08:15:43 +0000