There is no point in generating cpp files containing Q_IMPORT_PLUGIN()
macro calls for non-executable targets like modules, plugins and object
libraries in a static Qt build.
It causes unnecessary compiling of 10+ files for each of those targets.
In a static Qt build, plugin imports should only be done for executables,
tools and applications.
Pick-to: 6.0
Change-Id: Ied90ef2f6d77a61a093d393cfdf94c400284c4f0
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When a CMake release introduces a new policy that affects most Qt
modules, it may be appropriate to make each module aware of that newer
CMake version and use the NEW policy without raising the minimum CMake
version requirement. To reduce the churn associated with making that
change across all Qt modules individually, this change allows it to be
updated in a central place (qtbase), but in a way that allows a Qt
module to override it in its own .cmake.conf file if required (e.g. to
address the issues identified by policy warnings at a later time). The
policies are modified at the start of the call to
qt_build_repo_begin().
For commands defined by the qtbase module, qtbase needs to be in
control of the policy settings at the point where those commands are
defined. The above mechanism should not affect the policy settings for
these commands, so the various *Config.cmake.in files must not specify
policy ranges in a way that a Qt module's .cmake.conf file could
influence.
Starting with CMake 3.12, policies can be specified as a version range
with the cmake_minimum_required() and cmake_policy() commands. All
policies introduced in CMake versions up to the upper limit of that
range will be set to NEW. The actual version of CMake being used only
has to be at least the lower limit of the specified version range.
This change uses cmake_minimum_required() rather than cmake_policy()
due to the latter not halting further processing upon failure.
See the following:
https://gitlab.kitware.com/cmake/cmake/-/issues/21557
Task-number: QTBUG-88700
Pick-to: 6.0
Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The qmake build system defines _CRT_SECURE_NO_WARNINGS in
mkspecs/features/qt_module.prf, the cmake build system should do the
same thing in qt_internal_add_module().
Adding this definition can avoid warnings like:
warning C4996: 'strncpy': This function or variable may be unsafe.
As a special case, Bootstrap uses add_library() instead of
qt_internal_add_module(), so _CRT_SECURE_NO_WARNINGS should also be
defined in src/tools/bootstrap/CMakeLists.txt.
Pick-to: 6.0
Change-Id: Ic82193d177f82785fd84948efa78c49ca8d8db46
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In qt_internal_create_module_depends_file we're checking the target
property INTERFACE_MODULE_HAS_HEADERS. However, this property is not
exported, and in per-repo builds we do not have access to this.
As we cannot export INTERFACE_* properties, we export another one,
called _qt_module_has_headers.
This amends commit 598e873c84.
Fixes: QTBUG-88503
Change-Id: I04b3e24add6e95b577a049c80683b7361ff72f59
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Now all shared libraries and executables will get .debug files on
the platforms that support FEATURE_separate_debug_info
With the directory property _qt_skip_separate_debug_info certain
targets can retain the debug symbols in the binary e.g. lupdate with
MinGW 8.1.0 will cause objcopy / strip to fail.
Fixes: QTBUG-87015
Change-Id: I03b106e68ef0a42011d1ba641e6f686b2e7b7fb4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The QT.<module>.DEFINES assignment in pri files needs to take into
account the module name when computing the define name. This is the
MODULE value that qmake specifies.
In CMake that would be the value of CONFIG_MODULE_NAME.
Previously the value of the define was computed in
qt_internal_module_info() without taking into account the module name.
While qt_internal_module_info() ended being used also for plugins and
other target types, the defines computed by it were meant to be used
only for Qt modules.
Thus remove the <result>_define assignment from
qt_internal_module_info and move its computation directly into
qt_internal_add_module, taking into account the value of
CONFIG_MODULE_NAME.
The only other use of module_define was in qt_internal_add_plugin but
that was merely a long overdue copy-paste error, qmake doesn't
propagate QT_FOO_LIB defines for plugins.
As result, a define special case in testlib is not needed anymore,
because the define is now computed properly.
Finally, QT_FOO_LIB should not be used while building the Qt module
itself, so instead of using PUBLIC_DEFINES option of
qt_internal_extend_target, use target_compile_definitions(INTERFACE)
directly.
Change-Id: I4d44f7461bac2f0c09aec3e995d02dfe36e00883
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Instead of propagating the deprecation wranings, we compiled all code
with -Ddeprecations.
Change-Id: I0233ddc85bdbdcb93d366073b2cea5d47bdbe52a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Some of them have a different (hopefully better) name now.
Some are marked as Technical Preview.
Some are renamed to be internal.
Marking add_qt_gui_executable as TP with the intention to un-TP it
after we rename it and change its behavior as discussed in the API
review meeting.
Additional changes to add_qt_gui_executable and qt6_add_resources have
been filed as separate tasks that will be worked on separately.
See comments on PS1 for details.
Task-number: QTBUG-86827
Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add info whether Qt was an infix built, and whether the reduce_exports
feature was enabled. These variable were set before in
Qt5CoreConfigExtras.cmake.
Change-Id: Id077763cfffd5ee6f1a7a28d04cf92dc46390c54
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Supports installing linker generated debug info for shared libraries
and executables, as well as compiler generated debug info for static
libraries.
Works with Ninja Multi-Config as well, with the caveat that the files
are installed optionally, aka the install rule will not error out if
a pdb file is not present. This is necessary, because it's not
possible to create per-config install rules properly.
Fixes: QTBUG-87006
Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
To support finding Qt headers of modules installed into a different
prefix than the main one, add the $import_prefix/include path as a
public include path for each built Qt module. With this, includes like
#include <QtNetworkAuth/QOAuth2AuthorizationCodeFlow> will work.
The macOS framework case is handled automagically by CMake, which
ends up passing '-iframework $import_prefix/lib'.
Change-Id: I02ce9cacf157aab9721c1d6073a377607c5b89c7
Fixes: QTBUG-86881
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Building a user project in Release configuration against a Qt built with
CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project
being linked against the Debug Qt libraries. This is especially painful
with MSVC where debug and release runtimes are incompatible.
We now create *AdditionalTargetInfo.cmake files along the
exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties
to the values of the release config Qt was built with.
User projects built with an unknown
configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a
release Qt. This can be controlled by setting the variable
QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user
project.
Fixes: QTBUG-86743
Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Rename all libQt6*.so to libQt6*<infix>.so
Task-number: QTBUG-85438
Change-Id: I4b91ffaaec7bea61454b0d3c794c77f2d0868d54
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
All system frameworks use 'A' instead of the major version of the
framework, and Xcode's code signing assumes that the framework version
is 'A' when signing embedded frameworks (FB7323980), so leave the
version 'A'. This is also what Apple recommends.
Change-Id: Idbf2e30e156c3e869da8f75731e568524d9407e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Offer compatibility wrapper functions until we update all of the Qt
repos to use the new names.
Task-number: QTBUG-86815
Change-Id: I5826a4116f52a8509db32601ef7c200f9bd331de
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
For modules that have MODULE_INCLUDE_NAME set (for example ActiveQt) we
must use this name for the installation rules too.
Fixes: QTBUG-86484
Change-Id: I1b97cf534ea5e41655c7b3fdd0330b2f58356a3a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Configure Qt with -DQT_FEATURE_headersclean=ON to enable the
check. There will be separate target for each module include
(e.g. QtCore_header_check), but the check will also be done
when the module is built for the first time.
There are notable differences to the qmake version:
- the build does not pick up anymore default defines or flags from
the module, or Qt. Instead options like -fPIC they have to be listed
explicitly. Also for this reason, we have to skip the vulkan-related
headers from the check, since vulkan/vulkan.h is not necessarily
in the compiler's default search path.
- some checks for nowadays unsupported compiler versions are
removed.
- -Wdouble-promotion -Wshorten-64-to-32 is not added for clang
builds; the qmake code path did never enforce that on CI
machines (it was non-Apple clang only), and the check currently
fails on these configurations.
Fixes: QTBUG-82615
Change-Id: I1cd303677b1472116910b6c27748f96436feb35e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QtBuild.cmake is huge. Split it.
Move module, plugin, tools, executables and test related functions out
of QtBuild.cmake into separate files.
Do the same for many other things too.
An additional requirement is that all the new Helpers files only
define functions and macros.
No global variable definitions are allowed, nor execution of commands
with side effects.
Some notes:
qt_install_qml_files is removed because it's dead code.
Some functions still need to be figured out, because they are
interspersed and depend on various global state assignments.
Task-number: QTBUG-86035
Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
