Commit 18fc9e1bf8 introduced a
Windows-only QT_TOOL_PATH_SETUP_COMMAND to make it possible to
call the tool of a module while building the module itself.
The "set PATH=..." command in QT_TOOL_PATH_SETUP_COMMAND was flawed,
because it contained escaped double quotes which made the set command ineffective.
Fix this by removing the escaping of the double quotes.
This was uncovered when porting qtscxml to CMake.
Change-Id: I5909aa841e7895d6d0feb4037a935b805ccfdc99
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In QtSetup.cmake the PROJECT_VERSION_MAJOR variable was used to
identify prefix of 'Qt<version>HostInfoConfig.cmake'.
Qt<version>HostInfo is not found, if project version differs
from qtbase version.
Move the 'INSTALL_CMAKE_NAMESPACE' and 'QT_CMAKE_EXPORT_NAMESPACE'
variables to 'QtBuildInternalsConfig.cmake'. In this case
variables will be exposed for a wider list of internal routines.
Use the 'INSTALL_CMAKE_NAMESPACE' variable as prefix to find
Qt<version>HostInfo module.
Fixes: QTBUG-90345
Change-Id: Ic595d1c5beb74f34e69b58e18590a3afc2f346f7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add CMake upstream(3.20.0) version of FindPostgreSQL.cmake, to avoid
server-related headers lookup.
Avoid using the Qt version of the PostgreSQL module, if it's
older than the CMake's one.
Fixes: QTBUG-89639
Change-Id: I71a0c3508000901969933aea8a08d1ad431db711
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
By not including ASM in the languages for which compiler flags are
adjusted, we can end up with inconsistent optimization and debug
settings between different languages. Make sure they are treated the
same.
Similarly, linker flags for MODULE target types should also have their
debugging and incremental linking flags adjusted, just like EXE and
SHARED targets. When building with MSVC, MODULE targets were having
the relevant flags stripped, but not then replaced with the desired
ones, leaving them empty in typical scenarios. This would primarily
affect plugins, which are built as MODULE rather than SHARED libraries.
Fixes: QTBUG-90237
Change-Id: I648ea74be1654d24cbecc592ce0ca4b59b2ae839
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Make the document reflect the current status of the port.
Also link to https://doc.qt.io/qt-6/build-sources.html and
https://wiki.qt.io/Building_Qt_6_from_Git as official sources
on how to build Qt. This document should IMO rather
concentrate on documenting the build system internals.
Pick-to: 6.0
Change-Id: If62cb966b41b7452edb5b63725756916b66affac
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When building a repository != qtbase, like qtactiveqt, QMAKE_PRL_LIBS
contained entries like Qt6Core and Qt6Widgets, meaning the linker line
would contain exactly these arguments.
When building an activeqt example with qmake, the link then failed with
"LNK1181: cannot open input file 'Qt6Widgets.obj'".
The correct entry would have been $$[QT_INSTALL_LIBS]/Qt6Widgets.obj.
Fix this by determining the full path to the import library in the first
step of the prl generation. This enables QtFinishPrlFile.cmake to
recognize Qt6Widgets as Qt module and generate the right QMAKE_PRL_LIBS
entry.
Pick-to: 6.0
Fixes: QTBUG-90520
Change-Id: Id0d9178da0e0dfc3ea4fadbbe8f5900d792ffc84
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Add '_WINDLL' definition for the MSVC compilers family.
Check the 'FEATURE_optimize_size' value before replacing compiler flags
in the qt_internal_add_optimize_full_flags function. This is required,
because Qt::Core and Qt::Gui modules lost their ability to shrink,
when selecting the appropriate build type or features.
Fixes: QTBUG-89952
Change-Id: I982c25ea84e4793b4006ead0ee516b3f3eb2a054
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Commit d0071a4f87 broke static top-level builds:
CMake Error at .../qtbase/lib/cmake/Qt6Gui/Qt6GuiPlugins.cmake:17 (set_property):
set_property can not be used on an ALIAS target.
Fixed by moving the un-aliasing of the target before the set_property
call.
Pick-to: 6.0
Change-Id: I96c731353798a58ff9b3a664f3614ef03c897dcb
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Projects may call find_package(Qt6 ...) multiple times. When enabling
examples and tests, this happens a lot. For a statically built Qt,
for modules that have plugins (e.g. Gui), every time the module's
config file was loaded, it was generating and adding another copy of
the import plugin sources to the module target. These accumulated and
created many duplicates, which in turn blew out generation time and
made the build very inefficient.
This change checks whether the import plugin sources have already been
processed for the module target and ensures they are only added once.
It records its status on the target itself so that both local and
global targets are supported.
Fixes: QTBUG-90465
Change-Id: I1f45b1ee771a933ee755d44f1e983d6d9113dad0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This property is dynamically determined and set in the
Qt6${module-name}PluginsConfig.cmake files now.
There is no need anymore to export this property.
Change-Id: I2d164864c4099034b88f9ad852eae8b9f9e55f8b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
When doing a per-repository build of Qt, as it is done for the installer
packages, the build of qtbase has no knowledge of plugins that might be
built and installed from other repositories. That means we must not
write a fixed list of known plugins when exporting Qt modules of qtbase.
In particular, qtsvg adds imageformat plugins that are supposed to be
picked up by qtbase's QtGui module when linking a project against a
statically linked Qt.
${install-prefix}/lib/cmake/Qt6Gui/Qt6GuiPlugins.cmake missed the
include statements for qtsvg's plugin config files and operated on a
fixed list of plugins, all from qtbase.
Apart from that, the Qt6::Gui target's property QT_PLUGINS did only
contain the qtbase plugins.
This patch fixes the situation in the following way:
1. All Qt6*PluginConfig.cmake files in
${install-prefix}/lib/cmake/Qt6Gui are detected and included.
2. From those file names, the target names of the plugins are
deduced. This is safe as the file name of those generated files is a
direct result of the plugin's target name.
3. The QT_PLUGINS property of the module is updated with the detected
plugin target names.
Fixes: QTBUG-89643
Change-Id: Ifc3c39aa9948277ead5ebb209ec5eff64746308b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
'qt_manual_moc' doesn't provide include paths for 'moc' command to
substitute required macros. This change adds the
'INCLUDE_DIRECTORIES' and 'INCLUDE_DIRECTORY_TARGETS' arguments to
the 'qt_manual_moc' function.
If 'INCLUDE_DIRECTORY_TARGETS' is specified, 'qt_manual_moc'
collects 'INTERFACE_INCLUDE_DIRECTORIES' of provided targets and
uses them as the 'moc' include directories.
Change-Id: I58c8887dae3ca2484574c5e12e2cbd47f5bd3648
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Just like config_module_name is appended by "_private" in the case of
internal module pri, replace module_includes with the private one.
It fixes the issue where a pro file that uses an internal module pri
does not build due to missing paths to private headers.
Fixes: QTBUG-89961
Change-Id: Ice16a1e9f709d29454f1ddf5b954673cc06a88bb
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Jaeyoon Jung <jaeyoon.jung@lge.com>
Make sure to react on failed syncqt runs during the CMake run.
CMake will now report something along this:
```
syncqt couldn't parse .../qt5/qtbase/sync.profile: Can't modify modulus (%) in scalar assignment at .../qt5/qtbase/sync.profile line 25, near ");"
CMake Error at qtbase/cmake/QtModuleHelpers.cmake:192 (message):
Failed to run syncqt, return code: 255
```
Change-Id: I575a5fc926c547b6b633583e5d675f7e35beb734
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When building a Qt module against an installer-provided Qt on macOS, the
module pulls in the headersclean feature that creates the *_header_check
targets. Those targets try to compile the public headers of the module,
and the compilation command contains the -iframework argument. That
-iframework argument is supposed to point to the directory where the Qt
libs are installed. However, it pointed to the original
CMAKE_INSTALL_PREFIX of the machine where Qt was packaged.
Use the QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable instead
that contains the real installation location, even for an
installer-provided Qt.
Pick-to: 6.0
Fixes: QTBUG-90402
Change-Id: I27de8b3cc816488c2716042383b334d5c421452d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Move UNICODE and _UNICODE definitions from the public Qt::Platform
target to the private Qt::PlatformCommonInternal target.
Fixes: QTBUG-89951
Change-Id: Ib4c1c4cab74acda0a43c4ddb3cffd3954393dc89
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Replace package _LIBRARIES by _LIBRARY and _INCLUDE_DIRS by
_INCLUDE_DIR. Move find_package_handle_standard_args for Oracle and DB2,
since this call should set _FOUND variable but not separate condition.
Fixes: QTBUG-89866
Change-Id: I54be2c2c4d7ba4b849a27139702861ecd937c444
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
To be able to link a Release user project against a RelWithDebInfo Qt we
set several IMPORTED_*_RELEASE properties in
the *AdditionalTargetInfo.cmake file of each Qt module.
The EntryPoint module however is a bit special as it is an
INTERFACE_LIBRARY linking publicly against a static
library (EntryPointimplementation). Its *AdditionalTargetInfo.cmake file
was almost empty, because qt_internal_export_additional_targets_file was
called before EntryPointImplementation was set up. Also,
qt_internal_add_module, which calls
qt_internal_export_additional_targets_file, does not know that we want
to export the EntryPointImplementation target.
We fix this by telling qt_internal_add_module(EntryPoint) to not
generate the *AdditionalTargetInfo.cmake file and call
qt_internal_export_additional_targets_file later to take the targets
EntryPoint and EntryPointImplementation into consideration.
qt_internal_add_module learned the option NO_ADDITIONAL_TARGET_INFO to
turn off the generation of *AdditionalTargetInfo.cmake files.
Pick-to: 6.0
Fixes: QTBUG-90039
Change-Id: I68ec7125b538a57567035e7adb8dac3b213f95e6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The QtBuildInternals config package file gets processed before feature
evaluation occurs. That means INPUT_pkg_config may be defined, but the
corresponding FEATURE_pkg_config variable won't have been set/updated
yet. Do this check locally because the availability of a number of
features is conditional on whether pkg-config is available.
Change-Id: I6030eb380ee0c630ffbe5db5eed397a46227c7f6
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add an optional argument to store the report command while feature
evaluation-only stage. This is necessary, because according to the
actual feature evaluation process, evaluation happens only once and it's
impossible to record any command during the evaluation-only stage.
Fixes: QTBUG-90319
Change-Id: I215fbe0a28a2661cd2d97d253b2e2c787d295cbd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Jason McDonald <macadder1@gmail.com>
Functions in QtFlagHandlingHelpers.cmake try to update the CMake cache
variables for compiler and linker flags. These were using the current
value of those variables and writing the modified ones back to the
cache every time CMake ran. If a toolchain file sets or modifies any of
these variables, that updated value is used and written back into the
cache instead of the original cache variable's value. The next time
CMake executes, the toolchain file re-applies the same change and the
variable grows longer each time with flags repeated. With Ninja, this
causes a complete rebuild every time CMake is re-run. The Android NDK
toolchain file is one example where this behavior is triggered (the
fault is shared, one could argue that the NDK should only be setting
..._INIT variables, but that's out of our control).
Another related bug in the previous implementation was that the flags
used to build after the first CMake execution could be different to
those used for all builds after the second and later CMake runs. This
is because the CMake cache was being updated, but not always the
calling scope of the functions that modified them. If a toolchain file
set any of the compiler or linker flag variables as non-cache
variables, then updating the cache variable would have no effect on
the calling scope. The non-cache variable would continue to take
precedence for that scope for that run. The next time CMake executes
though, the updated cache variable would now have been used by the
toolchain file and the change *will* be part of the non-cache
variable's value.
The above are examples of why you should try to avoid updating these
cache variables from project code. We could leave the cache alone and
always update only non-cache variables, but then a developer looking
at the cache may wonder why the values they see there don't match the
values being used in builds. Or worse, they think the cache values
are being used and don't realize the builds are using something
different. Ultimately, we have to choose which downside we are happy
to live with. The changes here preserve the previous intent of
updating the cache, but it's still a bit fragile.
Fixes: QTBUG-89821
Task-number: QTBUG-85992
Task-number: QTBUG-86866
Change-Id: I8a16753e159bde338e6d2e5dd2ce91fc8ac5c39d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Ubuntu 20.04 is a supported platform and comes with CMake 3.16. The
current state of the Qt build works fine with this CMake version, mainly
because the default build on Linux is single-config.
For multi-config builds we have higher version requirements as
documented in cmake/README.md.
This lowers the barrier for users using single-config builds who don't
want or cannot upgrade to CMake >= 3.18.
For Ninja Multi-Config builds, which were introduced by CMake 3.17, we
yield a warning that 3.18.3 is the lowest supported version.
Pick-to: 6.0
Change-Id: Ia918b9f2b494508e86301ffc0e138d3ad4dbaf86
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
CMake <= 3.19 adds the '-fno-fat-lto-objects' compiler flag
unconditionally when CMAKE_INTERPROCEDURAL_OPTIMIZATION is enabled.
This is fine for shared libraries but static ones need the opposite
compiler flag.
Task-number: QTBUG-89426
Pick-to: 6.0
Change-Id: Ie5f48178803a270f6d94408f7a8e85d379eb123c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since test command variable may contain quotes, there is a warning
in generated test wrappers related to 'message(FATAL_ERROR', that
should display full command in log in case of error. To avoid any
complicated quoting of command to only display it, join command into
single string in wrapper script and pass resulting variable to
'message(FATAL_ERROR'.
Pick-to: 6.0
Change-Id: Ie990fc0b0bf2c19b119c7c4e2aeec092e5200103
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Use upper-level document build directory for generated .qch files. This
avoids copying of .qch with html documents and duplicating them in
the installation directory.
Pick-to: 6.0
Change-Id: I63b2de0047005419d352ea259dec6f17a826a477
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In latest Oracle Instant Client releases for windows the OCI library
name is 'oci.dll'. Add it as option to find_library call.
Change-Id: I6e6f4a998207d16583a380c1bd95db857051606b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add explicit error, if multi-config build is requested, but selected
generator doesn't support it.
Fixes: QTBUG-88287
Pick-to: 6.0
Change-Id: I6dba589bb59ad69fa07221c657df272ec75c359b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add output of feature condition error at the end of configuration
summary. Introduce qt_configure_add_report_error that may be used
to add error to end-point configure report without actual
configure interruption.
Fixes: QTBUG-88282
Change-Id: Idcf478da863ae6507438eb3370927d7d1f01e071
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This reverts commit 642ee46f98.
Reason for revert: Issue when command_count is actually 0
Pick-to: 6.0
Change-Id: I1b2603f25b56e3bd50cfc22a08925930ad231498
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Use LESS_EQUAL condition since qt_configure_command_count stores last
added command index but not actual count
Fixes: QTBUG-88054
Pick-to: 6.0
Change-Id: I8112820f9885bdad5a786a4f6b4890d8f2fbe14b
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Use the QT_MKSPECS_DIR instead of QT_SOURCE_TREE to find out the
location for the testserver feature's data. QT_SOURCE_TREE points to
qtbase source location, which may not be always available. This allows
to use this feature by projects outside of qtbase.
Task-number: QTBUG-85034
Change-Id: If7fa6ef95777be9acf35d36f8d99776bf9568a79
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Introduce a new QT_TESTSERVER_COMPOSE_FILE variable for setting a custom
docker compose file path, which can be set by projects outside of qtbase
(e.g. QtCoap). If the variable is not set, fallback to the compose file
located in qtbase.
Task-number: QTBUG-85034
Change-Id: I4c0c9b161cad9787b089ef7e9da2aa00352a9159
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
'QT_HOST_PATH' indicates that we use crosscompilation toolchain
to build project. In this case 'Qt6Config.cmake' loads
'Qt6HostInfoConfig.cmake' from host QT_HOST_PATH, that defines
correct paths to host tools.
Replace hardcoded paths for host tools by paths recorded
in Qt6HostInfoConfig.cmake.
Correct conditions for QT_HOST_PATH, evaluate it explicitly as
string, but not as boolean expression.
Fixes: QTBUG-86557
Pick-to: 6.0
Change-Id: Ib52bbd32478051d019a932dcb1f735e2d4aacfbf
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
With Ninja Multi-Config, QMAKE_LIBS_FOO_DEBUG and QMAKE_LIBS_FOO_RELEASE
are generated, if their values differ. In that case we did not create an
empty QMAKE_LIBS_FOO assignment. That, however, is needed to make the
library 'foo' known to qmake_use.prf.
This amends bd98ba0d17.
Fixes: QTBUG-89387
Change-Id: I80e23746e6ba6ff7f5f4186116232395814cee15
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Unset all QT_FEATURE_foo values for every build.
If any of FEATURE_foo is different of QT_FEATURE_foo, mark whole Qt
build as dirty. Reset FEATURE_foo for dirty builds to the calculated
value if it doesn't meet its condition.
Set Qt module as NOT FOUND if its target was not created during
configuration.
Main issue with this approach are generated files, that became trash
once the related features are disabled. This especially affects features
that enable/disable Qt modules. FooConfig.cmake files are created and
generate lots of warnings if feature was disabled. We may introduce a
module cleanup procedure at some point.
Fixes: QTBUG-85962
Pick-to: 6.0
Change-Id: Id71c1edb4027b24c6793063e40cc9d612c24ebce
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Build qtbase with -DFEATURE_static_runtime=ON, and then separately build
another module, following build error occurs:
error LNK2038: mismatch detected for 'RuntimeLibrary': value
'MT_StaticRelease' doesn't match value 'MD_DynamicRelease'.
That's because all the sources in this module are compiled with 'MD'.
When separately building a module except qtbase, FEATURE_static_runtime
is not exist in cmake cache. So we should use QT_FEATURE_static_runtime
instead of FEATURE_static_runtime in qt_set_common_target_properties.
Additionally, adjust the indentation.
Pick-to: 6.0
Change-Id: I2cf4737db9d3e8533570039a66c7d277d62a8d14
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When using MSVC compiler and -DFEATURE_static_runtime=ON, qrc_foo.cpp
and qtentrypoint_win.cpp are still compiled with '-MD' or '-MDd' flag,
which will cause following warnings and other possible problems:
warning LNK4098: defaultlib "MSVCRT" conflicts with use of other libs;
use /NODEFAULTLIB:library
Pick-to: 6.0
Change-Id: I6794930a64e9cff4dc1c9632fc3fc64227848af0
Reviewed-by: Yuhang Zhao <2546789017@qq.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The scripts that are used by Android test VMs are now located in qtbase
and are not easily usable by other modules. To fix that and allow other
modules to use those scripts, we install them with cmake into libexec.
Task-number: QTQAINFRA-4052
Pick-to: 6.0
Change-Id: Ibdd3658fd9fe7e007104a85d9999028a2de99a33
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
