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>
We should sync external headers for 3rdpary projects
like freetype and harfbuzz-ng and keep the directory
structure.
Fixes: QTBUG-113416
Pick-to: 6.6 6.5
Change-Id: Ie66edb9a21cff37ca6c8c68b6d225de6d8bbad81
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
This reverts commit 389507a047.
Reason for revert: The original patch unintentionally changes
the deprecation warning behavior for user projects. Merging
the current change will resurface the original static qt build
bug until a new fix is developed.
Pick-to: 6.6
Change-Id: I29b41b43fdd76b19bc46439470e04443dc2b8ddb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Yuhang Zhao <yuhangzhao@deepin.org>
Currently some libraries created by Qt are lacking some compile
definitions and compile options, and this issue is causing us
troubles when building Qt statically. This patch tries to reduce
the parameter difference when compiling Qt's own libraries.
Change-Id: I3842943a874fab32ef90980e8aa29f5beb01feeb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
qrhi.h, qshader.h, qshaderdescription.h (and qshaderbaker.h from
shadertools; done separately) become "RHI APIs", following the concept
of QPA APIs.
Mirror completely what is done for QPA headers, but using the "rhi"
prefix for the headers. This involves updating syncqt to handle the
new category of headers. (a note on the regex: matching everything
starting with "qrhi" is not acceptable due to incorrectly matching
existing and future headers, hence specifying the four header names
explicitly)
There is going to be one difference to QPA: the documentation for
everything RHI is going to be public and part of the regular docs, not
hidden with \internal.
In addition to the header renaming and adding the comments and
documentation notes and warnings, there is one significant change
here: there is no longer a need to do API-specific includes, such as
qrhid3d11[_p].h, qrhivulkan[_p].h, etc. These are simply merged into a
single header that is then included from qrhi.h. This means that users
within Qt, and any future applications can just do #include
<rhi/qrhi.h> (or rhi/qshader.h if the QRhi stuff is not relevant), no
other headers are needed.
There are no changes to functionality in this patch. Only the
documentation is expanded, quite a lot, to eliminate all qdoc warnings
and make the generated API docs complete. An example, with a quite
extensive doc page is added as well.
Task-number: QTBUG-113331
Change-Id: I91c749826348f14320cb335b1c83e9d1ea2b1d8b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
CMake doesn't resolve REALPATH for the non-existing files.
This limitation blocks the use of REALPATH when collecting the
generated module header files. The real path should be resolved
by syncqt implicitly and CMake scripts should rely on ABSOLUTE paths
only, which should be consistent for any files including the generated
files.
Task-number: QTBUG-113295
Pick-to: 6.5
Change-Id: I0219c7bf34ef6a6589c6d5fade4c2ed3f8036ef0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
The module information .json gained a "plugin_types" key in 6.5.0.
Unfortunately, this contained the "sanitized" version of plugin types,
meaning dashes converted to underscores. For plugin types that contain
dashes, e.g. wayland-decoration-client, the file contained
wayland_decoration_client, which doesn't match its plugin directory
name.
Since "unsanitizing" plugin names is hard and "sanitizing" is easy, we
now store the unsanitized plugin names and burden the consumer of the
module .json files with the sanitation task.
[ChangeLog][CMake] The module information JSON files now contain the
unsanitized plugin types of a module, e.g. wayland-decoration-client
instead of wayland_decoration_client. Consumers of the module
information file must sanitize plugin types themselves if necessary.
Pick-to: 6.5
Fixes: QTBUG-112872
Change-Id: I09cc9406b360779087086707abee3d5219a24452
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The source of the problem was in `qt_set_target_info_properties` which
was not able to process the NO_UNITY_BUILD_SOURCES, and therefore
leaking it into the `TARGET_COPYRIGHT`, ie., the last argument. So, I
decided to pass Unity Build arguments before them, and closer to
SOURCES, which is nicer to read, and avoid similar situation. And
I reverted the work around in the amend commit, and passing the
arguments normally.
This happens because we pass an unfiltered ${ARGN} from
qt_internal_add_executable to qt_set_target_info_properties and that the
current change is merely a workaround that ensures they get
circumstantially filtered out, because the NO_UNITY_BUILD_SOURCES option
appears before any of the first TARGET_ props.
Amend cd12c1f332
Task-number: QTBUG-99238
Task-number: QTBUG-109394
Pick-to: 6.5
Change-Id: Idb37937cf53e708425402c90f55bda8816e27f29
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add CMake rules to skip syncing and installation of header files
that are recognized as non-module. Previously these rules were in
syncqt.cpp only and CMake ignored them when creating the installation
rules. Now we skip any post processing for the header files that:
- are public and located in the '3rdparty' directory unless the module
is the 3rdparty one
- are not a part of the module source tree unless they are generated
- have the _qt_non_module_header property set to TRUE
Pick-to: 6.5
Change-Id: I045cfc2b8074f0c086c975aae95f14845e3edfef
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If Qt was configure with QT_NAMESPACE set, store that in the module
information files under 'built_with.namespace'.
Task-number: QTBUG-111158
Change-Id: I273309cb263c64f801dbb7238440336d7afa635e
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Properties specified in EXPORT_PROPERTIES have their values exported
verbatim, without evaluating generator expression they might contain.
This limitation is removed by the introduced functions. They collect
properties that needs to be exported and evaluate generator
expressions inside the properties using file(GENERATE) before
exporting them. The functions generate the ExtraProperties.cmake
file that contains set_property calls with exported properties
and corresponding values.
Change-Id: If32c30a82a62e8bd48bb91f3df21ff2ad8d07243
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
It doesn't seem like that it is being used anymore, except an instance
in pro2cmake which I replaced by NO_GENERATE_METATYPES.
Pick-to: 6.5
Change-Id: I135cf47e6041e98b354fb684f0079dad30689dea
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>
There was a plan to invert the API, but since the TODO, we are settled
on the non-inverted name, ie., GENERATE_CPP_EXPORTS.
Pick-to: 6.5
Change-Id: I84f531d870965e0b7d0d821d1ff08606ab8054ab
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Consider a cross build of Qt with qtbase, qtshadertools and
qtdeclarative. If a user projects only links against QtQml without
creating an actual QtQuick module, no host tools from qtdeclarative are
needed.
Normally, find_package(Qt6Qml) pulls in Qt6QmlTools and errors out if
it's not found. By setting QT_ALLOW_MISSING_TOOLS_PACKAGES when
configuring Qt, one can disable the error and build a user project such
as the one outlined above.
Pick-to: 6.4 6.5
Fixes: QTBUG-109547
Change-Id: I45e727713912d19e6007a7fbf3d61533f82b71d9
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jaeyoon Jung <jaeyoon.jung@lge.com>
As of f68e2c92cc, and its follow up
changes, we can now link individual plugins statically, even if the
Qt build is generally a shared build.
This allows us to build Qt for iOS as shared libraries, while still
keeping the platform plugin as a static library, since this is
harder to port over to a shared library.
This gives the benefit of faster turnaround during development, as
well as binary compatibility promises for the main Qt libraries,
without having to go fully shared for all of Qt.
Static builds are still the default, due to the downsides of larger
application bundles and slower load times for shared builds.
For now the user has to manually tick the "Embed & Sign" check
box in Xcode for each Qt library, which is only available with
Xcode projects generated by the qmake Xcode generator.
Task-number: QTBUG-85974
Change-Id: Id2b7bd2823c8e7c79068dda95295b574ada8d7f2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This simplifies deployment and eliminates the possibility
for duplicate downloads due to the browser/server not
understanding symlinks.
Change-Id: Ife22c052c424f309d76ff0f9118c01e98426da95
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This mimics CMake's policy support. The policy state is stored in an
internal __QT_INTERNAL_POLICY_<policy> variable; by using normal
variables, we gain support for stacking for free.
Policies can be explicitly en- or disable via qt6_policy; that command
also has a GET mode to retrieve them again.
Furthermore, one can now pass min and max version to
qt6_standard_project_setup, to opt in to a certain set of defaults
introduced in a given Qt version.
We add support for policies in QtModuleHelpers, so that we can check for
known policies while building Qt itself.
No actual policies exist yet; but a follow up commit will introduce one
for qt_add_qml_module.
Change-Id: I57a0404c9193926dd499f94cc5f73e359355c0b3
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Qt Creator maintains a mapping from Qt version to Android NDK version
and other build information. It's simpler to let the Qt build write the
Android build information into modules/Core.json and have Qt Creator use
this information.
This adds the following properties to the module JSON files:
- built_with.android.api_version
- built_with.android.ndk.version
Task-number: QTBUG-108292
Change-Id: I0febda5192289c5afb1a098880b31bef6317db35
Reviewed-by: Marcus Tillmanns <marcus.tillmanns@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The argument allows to ignore the condition for source files if they
are used in the Qt code without corresponding guards. The header files
of this kind usually have internal guards, that suppress the error
at the location where they are used, so AUTOGEN is skipped for these
header files to suppress the warnings from CMake. If file belongs to
a module, it will display AUTHOR_WARNING which should urge Qt
maintainers to guard the use of the source file properly.
Task-number: QTBUG-103196
Change-Id: I7b4c12031a5d19ff15868d4782c0d396ef7aed8c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
It looks like these targets used to manage some custom commands that
belong to HEADER_MODULES. We don't currently have a need to use them,
so we clean up the code.
Change-Id: I8095f4de2c91a6c310cccb9b89514c2ce77e32f0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
Some modules may have header files that do not pass headersclean check
under some conditions. It's nice to have an option in the
qt_internal_add_module function to disable the check for the modules of
this kind. At the moment this flag is useful for the ActiveQt module,
since it syncs and installs header files that don't belong to it.
Amends b89d63515b
Task-number: QTBUG-103196
Change-Id: I21a82d50d50bdac225ed483ab0cc50339c2a4873
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
Avoid the 'file' command shadowing by a variable and use file name when
filtering header files by type.
Amends 8539e641f6
Task-number: QTBUG-103196
Change-Id: If012975efafaf119cffbd89baf84df334bc057ac
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
<module>-config[-p].h files need to be added to the CMake source tree
Amends 8539e641f6
Task-number: QTBUG-103196
Change-Id: I8baaa672ad869da8a030d890da8bdea5bd8c7794
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Avoid adding module header files to a PUBLIC/PRIVATE_HEADER for the
modules. All header files are installed using install(FILES call, but
not as a part of install(TARGET
Amends 8539e641f6
Task-number: QTBUG-103196
Change-Id: Ib95295112c74f74f237e3738d2532f9049d26ce6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use CMake source tree when installing header files instead installing
all header files that syncqt.pl produces. This avoid adding header
files which cannot be used because of platform or feature
incompatibility with Qt version. Since syncqt.pl doesn't respect CMake
build tree when generating master header and CaMeL case header files,
these header files still will be installed regardless platform or
feature limitations. This will not be the case once we switch to
syncqt.cpp, which will install only headers that are relevant to the
selected platform and enabled features.
Task-number: QTBUG-103196
Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
HEADER_MODULE argument is passed to qt_generate_module_pri_file from
the qt_internal_add_module function, but the property means that the
module is an interface library. So it makes sense to replace this
argument with the reading of the target TYPE.
Change-Id: I1d8cd2ff732f526975cde6bdd4783fee44c8bd98
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The current qt_internal_extend_target interface expects that the caller
will pass the HEADER_MODULE argument on each call. This is not correct,
since the argument doesn't affect the target internals, but only help to
decide how to modify the target according to its type. The target type
meanwhile can be always read from target properties. So this solution is
more consistent.
Change-Id: Ie84a2226ceb71cb5272670e5d43bdfc7a101360a
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Add headersclean_check that allows to run all module-specific
'_headersclean_check' targets in single command. Also add
dependency on input header files for the headers clean custom
commands.
Also adjust the '_headersclean_check' target names to match
the naming of module targets - the 'Qt' prefix is removed.
Change-Id: I17c3442c3c51ce99cd9b38c85d606e9ababbb013
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
qt_copy_framework_headers now can accept all the headers in one call.
This is useful for upcoming changes when it will accept generator
expressions as the input instead of actual files.
Change-Id: I110b6d9e6de976b2a7581902e051e38571716c5f
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>
And take the opportunity to remove the "m" in the qmake feature name and
.prf file.
Pick-to: 6.4
Change-Id: I36b24183fbd041179f2ffffd170224ab75cdd968
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make the target purpose more understandable from its name.
Change-Id: I4f4a56fd3ef338b728d4a81edc2df32cada97f6c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When recording which package version to look for in
QtFooModuleDependencies.cmake and other files like it,
instead of using PROJECT_VERSION, use the version of the
package that contains the dependency.
For example if we're hypothetically building the qtdeclarative repo
from the 6.4 branch, against an installed 6.2 qtbase, then
the Qt6QmlModuleDependencies.cmake file will have a
find_package(Qt6Core 6.2) call because qtdeclarative's
find_package(Qt6Core) call found a 6.2 Core when it was configured.
This allows switching the versioning scheme of specific Qt modules
that might not want to follow the general Qt versioning scheme.
The first candidate would be QtWebEngine which might want to
follow the Chromium versioning scheme, something like
Qt 6.94.0 where 94 is the Chromium major version.
Implementation notes.
We now record the package version of a target in a property
called _qt_package_version. We do it for qt modules, plugins,
3rd party libraries, tools and the Platform target.
When we try to look up which version to write into the
QtFooModuleDependencies.cmake file (or the equivalent Plugins and
Tools file), we try to find the version
from a few sources: the property mentioned above, then the
Qt6{target}_VERSION variable, and finally PROJECT_VERSION.
In the latter case, we issue a warning because technically that should
never have to happen, and it's a bug or an unforeseen case if it does.
A few more places also need adjustments:
- package versions to look for when configuring standalone
tests and generating standalone tests Config files
- handling of tools packages
- The main Qt6 package lookup in each Dependencies.cmake files
Note that there are some requirements and consequences in case a
module wants to use a different versioning scheme like 6.94.0.
Requirements.
- The root CMakeLists.txt file needs to call find_package with a
version different from the usual PROJECT_VERSION. Ideally it
should look for a few different Qt versions which are known to be
compatible, for example the last stable and LTS versions, or just
the lowest supported Qt version, e.g. 6.2.6 or whenever this change
would land in the 6.2 branch.
- If the repository has multiple modules, some of which need to
follow the Qt versioning scheme and some not,
project(VERSION x.y.z) calls need to be carefully placed in
subdirectory scopes with appropriate version numbers, so that
qt_internal_add_module / _tool / _plugin pick up the correct
version.
Consequences.
- The .so / .dylib names will contain the new version, e.g. .so.6.94
- Linux ELF symbols will contain the new versions
- syncqt private headers will now exist under a
include/QtFoo/6.94.0/QtFoo/private folder
- pri and prl files will also contain the new version numbers
- pkg-config .pc files contain the new version numbers
- It won't be possible to write
find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code.
One would have to write find_package(Qt6WebEngineWidgets 6.94)
otherwise CMake will try to look for Qt6Config 6.94 which won't
exist.
- Similarly, a
find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call
would always find any kind of WebEngine package that is higher than
6.4, which might be 6.94, 6.95, etc.
- In the future, if we fix Qt6Config to pass EXACT to its
subcomponent find_package calls,
a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets)
would fail to find WebEngineWidgets, because its 6.94.0 version
will not be equal to 6.5.0. Currently we don't pass through EXACT,
so it's not an issue.
Augments 5ffc744b79
Task-number: QTBUG-103500
Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Output names of static libraries might be different from target names.
For example, the library name of Qt6::DeviceDiscoverySupportPrivate is
"Qt6DeviceDiscoverySupport.lib", and the library name of
Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib".
This commit make pdb files names consistent with the library names.
And make sure we have set correct OUTPUT_NAME property before calling
qt_set_common_target_properties()/qt_internal_set_compile_pdb_names().
Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
