Consider the following situation: There are CMake tests in
qttools/tests/auto/cmake that configure and build CMake test projects,
essentially as external projects. One of those test projects does
find_package(Qt6 COMPONENTS LinguistTools). This call fails in a prefix
build, because Qt6LinguistToolsConfig.cmake is not installed yet. It
merely exists in qttools-build/lib/cmake/Qt6LinguistTools.
We must adjust CMAKE_PREFIX_PATH to be able to find Qt6LinguistTools. We
also must adjust QT_ADDITIONAL_PACKAGES_PREFIX_PATH to be able to find
the LinguistTools component of the Qt6 package.
Use the prefixes setup from the support for building examples as
external projects and use it for CMake test projects as well.
Task-number: QTBUG-84884
Change-Id: I1bd5d5084cf931196bdb014cd75ca7578cd9decb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The former implies the latter, so it makes little sense to treat them
differently. Even if some types of targets are (currently) never
compiled with PCH, users of qt_internal_all_x() shouldn't need to know
such details.
Pick-to: 6.6 6.5
Change-Id: I8ead238a8d9e55da632b2929638b67724a42d73c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
CMake not necessarly sets MSVC or MINGW when detecting Clang compiler.
We should rely on CMAKE_CXX_COMPILER_FRONTEND_VARIANT instead when
detecting Clang platform.
Fixes: QTBUG-113630
Pick-to: 6.5 6.2
Change-Id: I8c14939ddc0839ddf2b3419392aa843deeef4bb5
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
If target platform is not detected the QT_QMAKE_TARGET_MKSPEC
variable remains empty. We need to check this explicitly.
Also store the default QT_QMAKE_TARGET_MKSPEC variable in the target
toolchain file. This is useful if users want to build repos
one-by-one or build standalone tests without the need to specify
the QT_QMAKE_TARGET_MKSPEC each time when configuring new repo or
tests.
Task-number: QTBUG-113630
Pick-to: 6.5 6.2
Change-Id: I57dfc6c97752a645868d77998d8f52e16bdfd5c8
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Supressing the linking warnings on macOS are relevant when we are
using AppleClang and not upstream Clang.
The provided arguments do not apply to llvm-ar and llvm-ranlib.
Change-Id: I8b664c01802b47077eb0ab80dab7681ee0bfcaa9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
- The following commands accepts NO_UNITY_BUILD, and
NO_UNITY_BUILD_SOURCES arguments to opt out of the unity build, and
to exclude some source files from unity build, respectively.
- qt_internal_add_executable
- qt_internal_add_module
- qt_internal_add_plugin
- qt_internal_add_tool
- qt_internal_extend_target
- qt_internal_add_common_qt_library_helper
- qt_internal_add_cmake_library
- qt_internal_add_simd_part
- Unity build is disabled by default in these:
- qt_internal_add_test
- qt_internal_add_test_helper
- qt_internal_add_benchmark
- qt_internal_add_3rdparty_library
- qt_update_ignore_pch_source also excludes the files from unity_build
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: I5d0e7df633738310a015142a6c73fbb78b6c3467
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This replaces the qt_parse_all_arguments macro with the built-in
`cmake_parse_arguments(PARSE_ARGV`. In addition, a new function,
_qt_internal_validate_all_args_are_parsed, can be used to check whether
any _UNPARSED_ARGUMENTS have been passed to the function.
Fixes: QTBUG-99238
Change-Id: I8cee83dc92dc6acdaaf747ea6ff9084c11dc649b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Alexandru mentioned that at the time qtdeclarative was still using the
variable, but from then, he replaced those as well, and I couldn't find
any usage anymore either.
Change-Id: I6a1893c2dfaa483dc8cb865f7bacf08cadca985b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The module description JSON files contain architecture-specific
information. Therefore they should reside below INSTALL_ARCHDATADIR
instead of INSTALL_DATADIR.
Moving these files should be unproblematic as there are no known users
of these files.
Change-Id: Ibff1f7b6ce2d1633ebce33861358ad5d1cae2beb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This adds a new platform named wasm-emscripten-64
which sets the build and link argument -MEMORY64
You may see this warning, please ignore at your own discretion:
em++: warning: -sMEMORY64 is still experimental. Many features may not work.
[-Wexperimental]
Fixes: QTBUG-104891
Change-Id: I8d3150d239ba72dbef5c2352e0171d6cfbe51b59
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Avoid using perl in CMake scripts. Remove the syncqt.pl specific
code.
Task-number: QTBUG-87480
Change-Id: I7fcd5cc83d173ec463c275b5b50b84f25044a118
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This allows one to add an extra set of directories to the build, but let
the compiler know that they are system paths (that is, the compiler
should refrain from emitting warnings in code found there). This extends
INCLUDE_DIRECTORIES and is by necessity a private include set.
Will be used by qtquick3dphysics, due to its PhysX dependency.
Change-Id: I76216ced393445a4ae2dfffd1729c556db0cce3d
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
syncqt.pl adds an extra dependency on perl when building Qt. Modern C++
provides the convenient cross-platform way to access a filesystem and
to use regular expressions, so we may replace the perl script with C++
application. The syncqt executable is built at configure time and
installed as QtCore tool. It's running at configure time to deliver the
required header files for IDE to build a consistent code model and at
the build time to keep tracking changes in header files and generate
the missing aliases without reconfiguring. 'syncqt' only parses header
files from a CMake build tree, so the resulting Qt installation only
contains interfacing headers that belong to the platform that Qt is
built for. 'sync.profile' files are not used as the 'source of truth'
for sync qt procedure anymore, all the necessary information is taken
from either CMake files at configure time or from the module header
files while parsing them.
syncqt.pl is still in place since it's required as fallback solution
for a smooth transition to the new syncqt implementation for all qt
repositories.
This patchset only enables the C++ based syncqt for 'qtbase'
repository.
From the performance perspective C++ version works faster then perl
script, also the configure time is reduced significally on subsequent
reconfigurations - up x2 times faster when re-configuring repository,
but it also takes time to compile the tool itself the first time.
Numbers for qtbase:
syncqt.pl syncqt.cpp
initial: 0m16,035s 0m20,413s
reconfig: 0m6,819s 0m3,725s
The syncing procedure can be run separately for each module using
<ModuleName>_sync_headers targets. The 'sync_headers' target can be
used to sync all the modules at once.
Task-number: QTBUG-87480
Task-number: QTBUG-103196
Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The _qt_internal_wrap_tool_command function has a limitation
that it is not possible to use it when a command needs to be wrapper
in a generator expression.
Provide a lower level API called
_qt_internal_get_tool_wrapper_script_path
to just get the path to the wrapper script, ensuring that the script
is created if needed.
Deprecate _qt_internal_wrap_tool_command, in favor of replacing it
with the new API.
Pick-to: 6.4
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: Ie4a4a17178bf2061ae01ee2b03b052d84560abf9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Instead of creating the tool wrapper shell script only
during a Qt build in QtBuild.cmake,
ensure it is created any time _qt_internal_wrap_tool_command is
called, regardless if we're building Qt or a user project.
As a transitional period not to break compatibility, we also need
to create the script in QtBuild.cmake, until all usages of
QT_TOOL_COMMAND_WRAPPER_PATH are replaced with function calls.
Currently such usages are present in qtdeclarative.
When considering which bin dirs to add to the script's PATH
environment variable assignment, in addition to the build
internals relative bin dir, also add QT_BUILD_DIR,
QT_ADDITIONAL_PACKAGES_PREFIX_PATH and QT6_INSTALL_PREFIX.
QT_BUILD_DIR is important so we always pick up the just-built
but not installed libraries in a prefix build when running just-built
tools.
QT_ADDITIONAL_PACKAGES_PREFIX_PATH is important when building examples
as ExternalProjects in prefix builds, to ensure that the
not-yet-installed tools and libraries are picked up from the repo
build dir, which is passed via QT_ADDITIONAL_PACKAGES_PREFIX_PATH
to the external projects.
QT6_INSTALL_PREFIX is there in case if the build internals relative
dir is located in a different places than the Qt6 package.
Pick-to: 6.4
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I4d76fbbc275ca961379971054f87991adac36539
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
It's needed for creating qmake build tests.
CMake / CTest has a limitation of not allowing to create single-config
tests when using a multi-config generator using the add_test(NAME)
signature.
Using add_test(NAME) forcefully creates per-config tests, which means
that it's not possible to just run ctest to execute tests, without
specifying a -C parameter, which we do in the CI.
qmake tests need to use the add_test(NAME) signature
to specify the WORKING_DIRECTORY option.
Because of the above limitation, a work around is to not use the
add_test(NAME) signature, but instead delegate the working directory
assignment to a generated cmake script, which
_qt_internal_create_command_script can already do.
Pick-to: 6.4
Task-number: QTBUG-96058
Change-Id: I6f439165994671724157f0edb7a71e351271e329
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The wasm helpers file is not included in QtBuild and is thus not visible
when standalone tests or other repos are being built. This fixes it.
Amends 1f9c1f032c
Pick-to: 6.4
Fixes: QTBUG-105615
Change-Id: I6c9229e1f259fa5043d7d11b8ee0293e26077f3e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
All references to these variables have been removed from Qt
repositories.
Change-Id: Icca4668ec183ff543d04097600f8a8869066f8cc
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Instead of checking if QT_HOST_PATH is set during user project
configuration to find out if Qt6HostInfo should be looked up,
record if QT_HOST_PATH was provided during Qt configuration
into Qt6Dependencies.cmake and look up the package in a user
project based on that information.
This improves handling of the case where cmake is directly used
to configure a Qt project (instead of qt-cmake), which means no
QT_HOST_PATH might be set by the user, and then cmake would error out
saying that e.g. Qt6CoreTools is not found, instead of saying that
Qt6HostInfo is not found.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I0377d5440e4b5b295af73cfd4b5188f61d48e440
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Also replace the duplicate call in QtSetup using the
new function.
To do that, we have to actually the call it in QtBuild
after QtPublicDependencyHelpers.cmake is available.
That call is needed so that Qt6_HOST_INFO_foo variables
are available in qt_generate_qmake_and_qtpaths_wrapper_for_target.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Ic5776c214bee6bedcea714b213b0e5a42c1bae06
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Replace BOOTSTRAP option with the single value CORE_LIBRARY argument
in qt_internal_add_tool and qt_internal_add_executable functions.
The introduced argument now may accept 'Bootstap' and 'None' values.
Use 'Bootstap' to link Qt::Boostrap library instead Qt::Core or 'None'
to avoid any core library linking. This is useful for tools that need
to use the CMake deployment routines, but not require the Qt::Core
functionality.
Task-number: QTBUG-87480
Change-Id: I64a8b17f16ac5fe43c6b385252dc21def0c88d2c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
There should be no need for CMake to add rpaths pointing to
directories outside of the build tree to the installed libraries.
All relevant install rpaths are handled by qt_apply_rpaths().
Change-Id: If554b1e3c790c2bb04a34e8b0524aab3febf5afc
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Allow such a combination
- staging prefix (CMAKE_STAGING_PREFIX / -extprefix) set to the
qtbase build dir
- install prefix (CMAKE_INSTALL_PREFIX / -prefix / on-device prefix) set
to some custom location
even for non-cross builds.
An example would be
configure -prefix /usr \
-extprefix ~/qt/qtbase_build_dir
CMake will put the Qt libraries in the qtbase build dir, ninja install
will not be required, but ultimately in order to run applications,
the Qt libraries are expected to be in /usr.
Support for this scenario was originally added for cross-builds in
062318feb2 , but not desktop builds.
Such a build is useful when you want to have install rpaths different
from where Qt is initially installed to (the staging prefix).
This case doesn't really happen often when targeting desktop
platforms, it's mostly used for cross-compilation (e.g yocto).
Being able to have the same setup with a desktop build is nevertheless
useful for faster iteration on build system issues in such a scenario.
Amends 062318feb2
Pick-to: 6.2 6.3
Change-Id: I42be3628a30025f14eebaf0a79401b54e95cde26
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
After the update to the CMake based build system the ability to
generate pkgconfig files, like it was with QMake, was lost.
This patch adds pkgconfig generation again via a new internal command
named qt_internal_export_pkg_config_file.
The functionality of this command consists in checking if the target
is internal. Then gets the compile definitions. It performs a search
for dependencies that is somewhat similar to
qt_get_direct_module_dependencies, although it won't recurse down for
more deps. Each dependency is then again, checked if it's internal or
has a public interface. Later these deps get deduplicated and lastly
a pkgconfig file is filled.
The resulting pkgconfig files of many of the Qt6 packages were
validated via invocations of `pkg-config --validate` and
`pkg-config --simulate` commands and later used to build local
projects plus tests that use the pkg-config provided details at
compilation time.
Although it has some limitations, with qt_internal_add_qml_module if
it specifies non-public deps these won't be listed and with non-Qt
requirements, notably in static builds, not being appended to the
PkgConfig file.
Task-number: QTBUG-86080
Change-Id: I0690bb3ca729eec328500f227261db9b7e7628f6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Qt6QmlMacros uses the value of GNUInstallDirs's CMAKE_INSTALL_LIBDIR
to calculate the rpath from a Qml plugin's location to the Qt
libraries.
By default CMake detects the value of CMAKE_INSTALL_LIBDIR, and on an
RHEL system it is set to 'lib64', whereas we usually configure Qt with
the lib dir set to just 'lib'. This might cause issues with Qml
plugins not locating the Qt libs due to an incorrect rpath.
Ensure that when building Qt libraries and plugins,
CMAKE_INSTALL_LIBDIR is set to the same lib dir value that Qt was
configured with.
Pick-to: 6.3
Fixes: QTBUG-99707
Task-number: QTBUG-100432
Change-Id: I17b2a22d46ef3b40084a2f6a4992f0e23b35d4d3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Use IMPORTED_LOCATION of rcc target when generating Android
deployment settings, instead of the hardcoded host path.
Introduce a helper function to find the location of the imported tool
target.
Change-Id: Icfa51ee7a01b3f58fc4892da03055f9ed531cc0b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add a "HURD" CMake platform specification, so it can be properly
checked in the build system.
Set QT_DEFAULT_MKSPEC to the existing hurd-g++ mkspec.
Hurd supports $ORIGIN in RPATH, so enable it.
Hurd uses X11, so add it to the X11_SUPPORTED list.
Enable few more feature checks that apply to Hurd as well: either
because they are provided by GNU libc itself, or because they are
implemented on Hurd.
Check and set the ELF interpreter, as it is a common functionality of
the GNU toolchain.
Change-Id: Id347033560bbc5a2a4e2c3abb493c948c002b40e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This amends commit 0bea727cac or rather
reverts it and applies a different fix for QTBUG-98843.
Use file(WRITE) instead of configure_file or file(CONFIGURE). This
command doesn't have the line endings issues in CMake 3.19 (see
QTBUG-98843). It's not problematic that the .bat file gets a new
timestamp on every configuration step, since we don't add dependencies
on it.
Fixes: QTBUG-99223
Task-number: QTBUG-98843
Change-Id: Ibdcd0e4703bf6df42c6a6d0bb2f35c5144bbe30a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
qt_setup_tool_path.bat did not have proper line endings on Windows with
CMake 3.19, breaking the invocation of tools that use the wrapper, for
example qmltyperegistrar.
The reason was that file(CONFIGURE) doesn't properly write line endings
with CMake 3.19. See upstream issue #21769.
Use configure_file with a proper input file to work around this issue.
Pick-to: 6.2
Fixes: QTBUG-98843
Change-Id: I2a4da15f306dc844cf83ca9721a77196c42af2ad
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And bump NTDDI_VERSION to 0x0A00000B (NTDDI_WIN10_CO) at the same time,
to unblock the developers from accessing the latest Windows APIs.
Pick-to: 6.2
Change-Id: Ifbc28c8f8b073866871685c020301f5f20dc9591
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
file(GENERATE) might fail if an unrelated configuration error happens,
and yet QT_TOOL_COMMAND_WRAPPER_PATH would already be set. Set the
cache variable only if generating was successful and replace the
QT_TOOL_COMMAND_WRAPPER_PATH valiable check with GLOBAL property to
protect the function from double call.
For CMake versions higher than or equal to 3.18 replace 'file(GENERATE'
call with 'file(CONFIGURE' to generate the wrapper at configure time
with the use of a plain semicolon character.
Pick-to: 6.2
Fixes: QTBUG-96870
Change-Id: Icf9c40f571d9c069043604f67ffcf2762966f6d0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This hasn't worked for some time. It's not in our CI and I don't think
it was working at all. When I tried to build it, I ran into several
problems with C++17 and an Internal Compiler Error I did not have any
interest in working around.
After discussing with the Intel compiler team, it was decided that
fixing those issues in the old compiler is not going to happen. Instead,
their recommendation is to adopt the new LLVM-based compiler, which
the last commit added support for.
This commit does not remove qmake support for the old ICC. It's possible
someone is using qmake with a non-Qt6 project and ICC.
Change-Id: Icb2516126f674e7b8bb3fffd16ad6350ddbd49e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The EXE_FLAGS option wasn't being used anywhere in any Qt repo
and it had no documentation as to its intended use. Remove it.
Pick-to: 6.2
Change-Id: I2f67ec57c1da7dc6eab81d5351361e770d19d7d5
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
There is no need for this variable to be stored in CMake's cache. We
don't perform expensive operations to set up QT_SYNCQT, and we even
unset the cache variable to ensure it gets recomputed on
reconfiguration.
We still store QT_SYNCQT in a global property, because the function
qt_ensure_sync_qt is called in different directory scopes, and we want
to avoid re-calculations for every subdir.
It's now possible for the user to set QT_SYNCQT (see QTBUG-88088 for
motivation). Also, in a non-prefix build, changes to syncqt.pl in the
source dir are reflected upon re-configuration in the build
tree (because qt_copy_or_install is called on every configure).
Pick-to: 6.2
Fixes: QTBUG-88088
Task-number: QTBUG-75290
Change-Id: I6137b060d200d3dafd4a64d5a6c1bd2549723d78
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Since platform definition directory is used as an interface include
path of the Qt::Platform target, it makes sense to define it for this
target only. Also the definition of cached values that contain
path to platform definition looks redundand.
The definition of QT_PLATFORM_DEFINITION_DIR from command line
doesn't make any sense since build procedure doesn't take it into
account when installing mkspecs and the use if the user-provided
QT_PLATFORM_DEFINITION_DIR value as a Qt::Platform include directory
causes inconsistency in the prefixed builds. INSTALL_MKSPECSDIR
and QT_QMAKE_TARGET_MKSPEC should be used instead.
Change-Id: I3636c57b835cb84511a358a0910cc482c5fbd81e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QT_BUILD_DIR should be used instead of CMAKE_BINARY_DIR as a base
directory for platform definition when building a non-prefixed
build since artifacts are copied to qtbase directory for top-level
build.
Amends 478f5fcde6
Pick-to: 6.1 6.2
Task-number: QTBUG-94973
Change-Id: I5cce16fdc7f760b954222ae67a4b85d4beea7f13
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Platform definition directory is defined when building qtbase.
Depending on the build type (prefixed/non-prefixed) it should point:
- To the source directory when building prefixed qtbase.
- To the installation directory of the prefixed qtbase when building
consumer projects.
- To the build directory of non-prefixed qtbase when building
non-prefixed qtbase or consumer projects.
TODO: It is desirable to move the logic asssociated with Qt platform
definition to the qt_internal_setup_public_platform_target function.
Pick-to: 6.1 6.2
Fixes: QTBUG-94973
Change-Id: I8530613f9b2029834c66206bbdf02475528a4640
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If user specifies non-existing platform build fails in some non-obvious
place, since qplatfromdefs.h couldn't be found.
Add an explicit error if the defined platform folder doesn't exists in
Qt sources.
Change-Id: Id847d57a6f9cc4f463e697b474b8a669cd041fb8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Dependency lookup mechanism is the same for modules and plugins. It
makes sense to wrap it using macro.
Pick-to: 6.2
Change-Id: I73727743b0f5f40b2d94624f65ebfcf85e8dcc59
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This makes qt_internal_disable_find_package_global_promotion available,
which is needed when linking against QtMultimedia in a static build
Pick-to: 6.2
Change-Id: I9b8f6d7b74a8693ac471f8a280e893f4da80a44b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qmake had support for building with clang-cl as the win32-clang-msvc mkspec.
Task-number: QTBUG-89642
Task-number: QTBUG-88081
Change-Id: I0709c289f90fedb121620d1e67ef841602219816
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
All repositories define QT_NO_INTERNAL_COMPATIBILITY_FUNCTIONS by now,
and we can remove QtCompatibilityHelpers.cmake altogether.
Change-Id: I4d8104246e96a4514d5651c104607d651d208d95
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Introduce the concept of repository target sets, which is a named set of
targets within a Qt module repository.
In a Qt repository, a repo target set 'qtfoo' can be defined in the
top-level project file with
qt_internal_define_repo_target_set(qtfoo DEPENDS Bar Baz)
The DEPENDS argument specifies Qt components that need to be
find_package'd when building the targets that belong to qtfoo.
In subdirectory project files, use
qt_internal_include_in_repo_target_set(qtfoo) to mark the file as
belonging to the repo target set.
To build and install a single repo target set, specify
QT_BUILD_SINGLE_REPO_TARGET_SET=qtfoo when configuring the Qt
repository.
Change-Id: Ic9e6213e3225988fd561f315bc857ee44ff17420
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Needed for the upcoming static plugin mechanism, where we have to
extract the list of Qt module dependencies of a target and then extract
the plugins associated with those modules.
To do that we need to recursively collect the dependencies of a given
target.
Rename the moved functions to contain the __qt_internal prefix.
Also rename the existing QtPublicTargetsHelpers.cmake into
QtPlatformTargetHelpers.cmake to avoid confusion with the newly
introduced QtPublicTargetHelpers.cmake.
Task-number: QTBUG-92933
Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
