summaryrefslogtreecommitdiffstats
path: root/cmake
Commit message (Collapse)AuthorAgeFilesLines
* 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>
| * Do not write Sysroot and SysrootifyPrefix into qmakeconfig.cppJoerg Bornemann2021-03-111-2/+0
| | | | | | | | | | | | | | | | Those have fixed values. Change-Id: I7f1ba8036f43413d3c805f4b419ae79e037343fb Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* | Bump Apple platform minimum versionsAlexandru Croitor2021-03-101-3/+3
|/ | | | | | | | | | | | | | | | | | | | | | Includes both minimum deployment targets and minimum sdk versions. As per supported Apple platforms versions which was done in qt/qtdoc at 8807fdedce29cbbd7662fcd745234da30eace3fb For Qt for iOS 6.0.x we only bump the minimum deloyment target because applications seem to crash with iOS 12.4+, and it's better to have a build error than a runtime error. The minimum required sdk will not be bumped for 6.0.x, so we don't accidentally break someone's existing build, given that 6.0 is already released. Pick-to: 6.1 Task-number: QTCREATORBUG-23574 Change-Id: I3046384164f2d7fdbd0cfd16dcb85e0d60bc56ce Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
* qtdeclarative now directly handles more qml-specific logicCraig Scott2021-03-103-12/+5
| | | | | | | | | | | | | | | | | Associated changes in the qtdeclarative repo now ensure that arguments for qml plugins are handled on the calling side. This reduces the qml-specific logic needed in qtbase and gives qtdeclarative clearer control over qml build and install locations. As part of that work, the INSTALL_LOCATION keyword used in qt_internal_record_rcc_object_files() has been renamed to INSTALL_DIRECTORY to make it consistent with the keyword used for the same concept in other commands. Pick-to: 6.1 Change-Id: Iebd319899f63d79fbe15ce965b84ce324c28a508 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* configure: Fix error when turning on/off non-emitted featuresJoerg Bornemann2021-03-091-14/+14
| | | | | | | | | | | | | | | | | Features that are not emitted in the current configuration (e.g. plugin-manifests on Linux) should not yield an error. Instead, print a warning message like Qt5's configure did. Set insignificant feature to OFF. Remove the now unneeded emit_if parameter from qt_feature_set_cache_value. Pick-to: 6.1 Fixes: QTBUG-88305 Change-Id: I0f2ce152fca5f08417038c9bd2c07639ff6a3df4 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* cmake: Extend qt_configure_add_summary_section by a message typeDominik Holland2021-03-091-0/+2
| | | | | | | | | | | With the existing types we can only display a list of features or whether a feature is on or off, but we cannot display arbitrary values. Using the new message type, it is possible to show paths or versions as summary entries. Change-Id: I5d16cb4b30923f3566755bd4d7440bdd1ece82f5 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Add QT_CONFIGURE_RUNNING variable for configure.cmake filesJoerg Bornemann2021-03-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | configure.cmake files are read twice when using the configure script / qt-configure-module: First, when configure is running and a second time, when CMake creates the local build system files. In the first run, not every function and esp. no targets are available. Code in configure.cmake that accesses targets or calls functions unknown to configure will fail at the configure stage. This patch introduces the QT_CONFIGURE_RUNNING variable that can be used in configure.cmake files to guard such code: if(QT_CONFIGURE_RUNNING) set(_qt_coord_type double) else() get_property(_qt_coord_type TARGET Qt6::Core PROPERTY INTERFACE_QT_COORD_TYPE) endif() Change-Id: Iff39924d6a5133379d28c8204d7b7afdf47de5c8 Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
* Merge "Fix build of Core module without regularexpression feature"Alexey Edelev2021-03-041-3/+3
|\
| * Complete the renaming of qt_add_tool to qt_internal_add_toolJoerg Bornemann2021-03-041-3/+3
| | | | | | | | | | | | | | | | | | | | Fix the name in the function's doc comment and error messages. Pick-to: 6.1 Change-Id: I918db802a0dbb0508f65d227f7c896d2ad0beeae Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* | Merge "Remove win32_system_libs feature from src/corelib/configure.json"Joerg Bornemann2021-03-043-9/+49
|\ \
| * | Move syncqt.pl to libexecJoerg Bornemann2021-03-041-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To not disturb the qmake build we kept syncqt.pl in <src>/bin but installed it to libexec. This is not necessary anymore. This also removes the need for having syncqt.pl in both, bin and libexec in the build dir of qtbase. Pick-to: 6.1 Fixes: QTBUG-91076 Change-Id: I44b014ea41e3f00c420e02fd5c76f11169340b8c Reviewed-by: Kai Koehne <kai.koehne@qt.io>
| * | Make toolchain inspection more robustJoerg Bornemann2021-03-042-4/+48
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | QtAutoDetect.cmake did read the (possibly detected) toolchain file and looked for the string "The Android Open Source Project" to deduce that we want to build for Android. This has been done, because we're autodetecting the platform before the first project comment, i.e. before the toolchain file is loaded. This magic string detection is a bit fragile, and we need a similar approach for WebAssembly. A more robust approach would be to fetch the value of CMAKE_SYSTEM_NAME from the toolchain file without actually loading it. Now, we run a CMake script that includes the toolchain file and prints variables were interested in. The calling code reads these variables and stores them in prefixed variables in the current scope. Change-Id: Ide9ea3054e1453d17129523e1ec86ecaed55af2a Reviewed-by: Craig Scott <craig.scott@qt.io> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* / headersclean: Compile with -std=c++latest, -Zc:__cplusplus on MSVCKai Köhne2021-03-041-1/+1
|/ | | | | | | | | | | c++latest does check that our headers also work with upcoming C++20 support in MSVC. It also implicitly sets -permissive-, which checks for stricter standards compliance. Pick-to: 6.1 Task-number: QTBUG-91117 Change-Id: Iaf1547191969213d570a1b2f59888ad04a7977ab Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Improve support for QT_ADDITIONAL_PACKAGES_PREFIX_PATHKai Köhne2021-03-033-4/+12
| | | | | | | | | | | | | | | | | | | Allow to set QT_ADDITIONAL_PACKAGES_PREFIX_PATH as both an env variable and CMake cache variable. Also normalize path and list separators, so that they can be used similar to CMAKE_PREFIX_PATH. The environment variable is intended to be set by the conan virtualenv generator, so that e.g. find_package(Qt6 COMPONENTS NetworkAuth REQUIRED) also works if NetworkAuth is not installed into the Qt prefix. Pick-to: 6.1 Fixes: QTBUG-91142 Change-Id: Ia9f9b9fa2b1b051d33073629139640d0f4c7a843 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io> Reviewed-by: Craig Scott <craig.scott@qt.io>
* Generate information about user-facing applications in build dirJoerg Bornemann2021-03-024-1/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When packaging different Qt versions for Linux distributions (or any distribution with a common bin dir), Qt tools cannot be installed to /usr/bin, because the executable names of the different Qt versions clash. To solve this conflict, our recommendation is to install Qt's tools to /usr/lib/qt6/bin and to create versioned symlinks to user-facing tools in /usr/bin. User-facing tools are tools that are supposed to be started manually by the user. They are marked in Qt's build system. Distro package maintainers can now configure with -DCMAKE_INSTALL_PREFIX=/usr -DINSTALL_BINDIR=/usr/lib/qt6/bin -DINSTALL_PUBLICBINDIR=/usr/bin and will find a file called user_facing_tool_links.txt in the build directory after the cmake run. Nothing will be installed to INSTALL_PUBLICBINDIR. Each line of user_facing_tool_links.txt consists of the installation path of a user-facing application followed by a space and the versioned link name in INSTALL_PUBLICBINDIR. Example content: /usr/lib/qt6/bin/qmake /usr/bin/qmake6 To actually create the versioned symlinks, the content of this file can be fed to ln like this: xargs ln -s < build-dir/user_facing_tool_links.txt Or the package maintainer may decide to do something completely different as suits their needs. This patch adds the USER_FACING argument to qt_internal_add_tool to mark tools as user-facing. In addition, every Qt created by qt_internal_add_app is treated as user-facing. The only tool this patch marks as user-facing in qtbase is qmake. Pick-to: 6.1 Fixes: QTBUG-89170 Change-Id: I52673b1c8d40f40f56a74203065553115e2c4de5 Reviewed-by: Kai Koehne <kai.koehne@qt.io> Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
* Make qt_get_module_for_plugin() internal and do what its name saysCraig Scott2021-03-021-12/+7
| | | | | | | | | | | | | | | | | | Contrary to its name, this command was also setting a target property. Since it was only called in one place and that caller can just as easily set the property instead, rename the command to make clear its internal nature and refactor it so that the caller is responsible for setting that property instead. Also make it an error rather than just a warning if the command is used for a target that doesn't belong to any module. Since this is now unambiguously an internal command, we should always expect the target to belong to a module. Pick-to: 6.1 Change-Id: I929a652ddd482653868fc9df887f38f4bc7f35d9 Reviewed-by: Ulf Hermann <ulf.hermann@qt.io> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Simplify prefix-related functionality of qmakeAlexey Edelev2021-03-011-9/+0
| | | | | | | | | | | | | Since the QT_CONFIGURE_HOSTBINDIR_TO_HOSTPREFIX_PATH and QT_CONFIGURE_HOSTBINDIR_TO_EXTPREFIX_PATH definitions keep the same value in modern CMake build, no need to have special handling in cases where these values are used in qmake. Also it will be useful to specify the relative path to the prefix directory from the directories different of 'bin' when use QMakeLibraryInfo. Task-number: QTBUG-75870 Change-Id: I5a777001eb334dcf05e22853a514d4257352d59b Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Use Core library for qmake instead of the Bootstrap libraryAlexey Edelev2021-02-254-24/+9
| | | | | | | | | | | | | | | | | | | Move the qmake-specific logic of the QLibraryInfo class to qmake internals. 'qconfig.cpp.in' now stores information about the library info entries to keep them consistent between qmake and the Core library. qmake requires specific features enabled in the Core library, so building qmake will be skipped if the features are not enabled. All flags directly related to the qmake have been removed from Core lib. Remove all bootstrap related sections from qmake CMakeLists.txt Task-number: QTBUG-89369 Change-Id: I26de157d3bfd4a5526699296e9d46e1c180b89ae Reviewed-by: Edward Welbourne <edward.welbourne@qt.io> Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* Remove INTERNAL argument from qt_internal_add_linker_version_scriptJoerg Bornemann2021-02-251-34/+30
| | | | | | | | | The code branch for the INTERNAL argument did nothing, and we never call qt_internal_add_linker_version_script with INTERNAL. Change-Id: Ie369b4dac29cd1a977433ebfd662c198a3e1d0f2 Reviewed-by: Alexey Edelev <alexey.edelev@qt.io> Reviewed-by: Cristian Adam <cristian.adam@qt.io>
* CMake: Prevent qt_remove_args() from accessing out-of-range list indexCraig Scott2021-02-241-0/+4
| | | | | | Pick-to: 6.1 Change-Id: Ie9c5f0551722c7d3fb11879b209c11ce3d7ccd6d Reviewed-by: Kai Koehne <kai.koehne@qt.io>
* CMake: Reformat shared keyword listsCraig Scott2021-02-241-12/+63
| | | | | | | | | | | | Putting each keyword on its own line makes it much easier to read and improves maintainability. It is friendlier to source control when keywords need to be added or removed. This commit introduces no functional change. Pick-to: 6.1 Change-Id: I79efd039e5afa5f11f1d859405d6487ad6b3beb2 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Avoid cyclic dependency between plugin and module *Config.cmake filesCraig Scott2021-02-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | In static per-repo builds, we have a mix of targets provided by packages and targets provided by the main build. For the builds that create the packages, we must avoid adding a dependency for the main module library target on its associated plugin targets or else the package config files end up with a cyclic dependency that cannot be resolved when something tries to consume them. This only happens for static builds because we have been attaching a linking relationship to the main module library that isn't really a true dependency, we attached it only for convenience of things linking to that module library. To preserve that convenience linking without breaking the config packages, we use the QT_NO_CREATE_TARGETS condition to prevent CMake seeing that relationship when generating the *Config.cmake files. Creating these relationships will be delayed until the plugin's *Config.cmake file is loaded, at which point it will add itself to the main module library's imported target INTERFACE (this was already done before, we just now rely solely on that). Task-number: QTBUG-90819 Pick-to: 6.1 Change-Id: Id725742182bcda64841be84fe1650bafb9151bb1 Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* cmake: Don't give plugins PUBLIC usage requirementsCraig Scott2021-02-241-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | The pro2cmake.py conversion script faithfully reproduced the .pro files for the plugins, which specified the libraries as public. But in CMake, the implications of this are that public usage requirements should then be propagated to consumers. We don't expect any consumers, since a plugin is created as a MODULE library in CMake, so for Windows we don't even have an import library to link with. The only exception to this is for static builds where plugins are created as STATIC libraries instead, but only in certain controlled situations do we then link to plugins. Even then, usage requirements are not expected to propagate to the consumers, so these relationships should always be specified as private. This change warns on any PUBLIC usage requirements specified for a plugin. This check is disabled by default to avoid spamming CI builds for repos that haven't been fixed yet. The check can be enabled by a CMake cache option, which is intended for developers to use locally when fixing this issue in other repos (all plugins in qtbase should not trigger this warning as a result of changes in this commit). Task-number: QTBUG-90819 Pick-to: 6.1 Change-Id: I09f2c8da77db1193ad3370f85d367dfc6ab7b9a6 Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org> Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Move build tools to libexec instead of the bin dirJoerg Bornemann2021-02-231-1/+1
| | | | | | | | | | | | | | [ChangeLog][Build System] Tools that are called by the build system and are unlikely to be called by the user are now installed to the libexec directory. This is a step towards easier co-installability of different Qt versions. Pick-to: 6.1 Task-number: QTBUG-88791 Change-Id: Id19575b5ba27795f7715e4ea6a09391b26dd4942 Reviewed-by: Kai Koehne <kai.koehne@qt.io>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-19 00:33:49 +0000