Passing arguments with equal signs was broken for configure.bat and
qt-configure-module.bat. An argument FOO=BAR was split at = and written
as
FOO
BAR
to config.opt, breaking every attempt of assigning CMake variables.
We must not iterate over %* in batch files to avoid splitting arguments
at equal signs. Instead, pass %* unmodified to a CMake script that
writes config.opt.
Fixes: QTBUG-88019
Change-Id: I7c743a206961d1ed168f2313f864905f6b345b49
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In a subsequent change we will call another CMake script from
qt-configure-module.bat. Write the location of qtbase/cmake into the
generated scripts instead of the path to QtProcessConfigureArgs.cmake.
Change-Id: Ie333b16d310b215c6e49efa27740c7525453d28f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMake considers ON/OFF as booly string values regardless of the case.
Make the value comparison in QtFeature.cmake case-independent.
It's now possible to build Qt with '-DFEATURE_gui=off'.
Fixes: QTBUG-87948
Change-Id: I3d948e8219ad9728414803c8c4cd756034073b46
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Rolf Eike Beer <eb@emlix.com>
Previously we determined if a library represented by an absolute path
is a Qt module by checking if it's located in the build dir of the
current repo.
That is not sufficient for non-qtbase prefix builds, where
a Qt module might link against both a module in the current
build dir and in the prefix dir.
Detect such cases, and rewrite the absolute paths to relocatable paths
(either framework flags or paths starting with $$[QT_INSTALL_LIBS].
This should fix building examples with qmake that use QtQuick.
Fixes: QTBUG-87840
Change-Id: Icaf8f1a7c66292c80662fd0d5771a5a1628a9899
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add an EXTRA_CMAKE_FILES argument to qt_internal_add_tool()
that allows tools to install an additional Macro.cmake file.
This is modelled after similar functionality in qt_internal_add_module.
Task-number: QTBUG-87870
Change-Id: I80838b8966f1018fdd379b1da877b6bc418de075
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Fixes a regression introduced in commit 748b3b9c89 for builds
that are both not a QT_SUPERBUILD and not QT_WILL_INSTALL.
Change-Id: I52b920176a2696fa6206b89b2b69ae1a7f3fbc25
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The top-level prepare_docs target is supposed to run before the
generate_docs target.
The repository-level targets like prepare_docs_qtbase now also run
before their respective generate targets.
To achieve that, several intermediate targets had to be introduced.
The dependencies for top-level generate_docs look like this:
/--> generate_top_level_docs_Core --\
generate_docs ---> generate_top_level_docs_Gui -----> prepare_docs
\--> ... --/
The dependencies for repo-level generate_docs_<repo> look like this:
/--> generate_repo_docs_Core
generate_docs_qtbase ---> generate_repo_docs_Gui
\--> ...
generate_repo_docs_Core --\
generate_repo_docs_Gui -----> prepare_docs_qtbase
... --/
Analoguous for qch_docs.
And last but not least, the module-level generate_docs_<module> depends
on prepare_docs_<module>, just like before.
The strangely named top-level install targets have been renamed to
install_html_docs, install_qch_docs and install_docs.
The html_docs target is now merely an alias for generate_docs.
Apart from prepare_docs, the top-level targets do not depend on the
repository-level targets anymore. Targets that are just an alias (docs,
install_docs, ...) have been re-defined to depend just on the respective
top-level targets.
Fixes: QTBUG-87758
Change-Id: I24466d3a252d518a30a2064bf876be881c46231f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The value is useful for QPA plugins built in repos other than qtbase,
to decide if it should be a default plugin or not.
Currently useful for qtwayland.
Also export a qmake value assignment when doing static builds, just
like src/gui/configure.pri does.
Change-Id: I1253f1a7e178b24b16e2615ba20d1e92b0b87b1a
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Otherwise we get error messages from CMake.
Change-Id: I374b87e38550062b841b7eacf5fbb6bb5ccbdbde
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Allow CMake for Android to use ANDROID_NDK_ROOT to deduce the path for
QT_CHAINLOAD_TOOLCHAIN_FILE instead of the user providing it manually.
Change-Id: Ida728011d5ca8d5a723d341ea77b173e8f105f8c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is meant to be called by our CI instructions to build standalone
tests of a Qt repository.
Currently it just calls qt-cmake with
-DQT_BUILD_STANDALONE_TESTS=ON, but it might contain more things in
the future.
The script also simplifies configuring standalone tests locally, due
to not having to remember the name of the magical variable.
Change our CI instructions to use the new script.
Change-Id: I6bc02b4e94adc9d0d05fecb0fe70a561043271f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
With the introduction of the new 'default_qpa_plugins' custom target,
a target dependency cycle occurred in qtwayland:
qtwaylandscanner -> default_qpa_plugins -> a wayland qpa plugin ->
WaylandClient -> qtwaylandscanner
The issue is twofold:
- default_qpa_plugins accidentally depended on non-qpa plugins.
- All qpa plugins were enabled by default, including the wayland ones.
Fix the default_qpa_plugins target not to depend on regular non-qpa
plugins.
Also fix qpa plugins not to be enabled by default, but instead only
choose one qpa plugin to be the default (via evaluating the
DEFAULT_IF) condition.
Amends df9c7456d1
Change-Id: I22cd2c72f6b75be54263fd21097258bd179e3616
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The way we detected whether SysrootifyPrefix needs to be set was
incorrect.
We checked if extprefix == prefix => SysrootifyPrefix should be
true. But that was previously always the case for a non-prefix build,
which means it was not possible to build apps (due to qmake expecting
to find include dirs in the sysroot, despite the non-prefix Qt not
being installed anywhere into the sysroot).
Instead we should do what qmake does. Only set SysrootifyPrefix to
true if extprefix was not provided and a sysroot is available.
To make it work for iOS and Android, the sysroot detection code had to
be moved earlier than the SysrootifyPrefix detection.
Task-number: QTBUG-86053
Change-Id: Idcc1260a675fb2ef9ae27fc9dc42a68b30f763b8
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The html_docs target does not need to call QDoc a third time as
both its dependencies already do that.
With qmake, html_docs did invoke QDoc if CONFIG did not include
'prepare_docs', but none of the Qt modules used that configuration.
We can manage without it for now.
Fixes: QTBUG-87751
Change-Id: I45d2d06006c566c431ae41d7f3a06d6b809987f2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
For top-level builds it's desirable to have "ninja generate_docs" build
all tools needed to generate the documentation.
This is problematic since the doc-generating targets are created before
the doc tool targets. Thus, we must defer the dependency connection if
the doc tool target is not yet available.
This patch adds the functions qt_internal_defer_dependency and
qt_internal_add_deferred_dependencies.
Change-Id: Ica940b80882e67cb0e0943e95541f7f4d1885948
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
qmake treats internal modules as just the regular module file,
but with a _private suffix, as opposed to the current cmake
logic, that treats it as the private module file, resulting
in missing e.g. the Qt.foo.module entry.
Change-Id: Id55ca4c23921656d5abfd1d0fdf6430d4fe120bf
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This patch allows in top-level prefix builds to build Qt and to generate
the documentation without running cmake --install first.
For top-level builds we now always use the qdoc binary from the build
directory, not the installation directory.
We also have to copy the global doc files to the build directory to make
them accessible to the generate_docs target.
Change-Id: I2251603418fc3df9a21c7f2892789e9ff6c8cc21
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's not sufficient to pass -I{prefix}/include when doing the header
clean check.
We need to propagate all target include directories and compile
definitions, and also the compile flags for good measure.
For macOS frameworks we also need to explicitly pass an -iframework
flag (qmake passses -F instead), to ensure that <QtGui/qfoo.h> style
includes are found when building other repos than qtbase.
Task-number: QTBUG-82615
Change-Id: I76d12340bc01c5c948ff04df9a3df384dcb7e076
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This ensures ccache or sccache is used to cache the compilation of the
headerclean checks.
Task-number: QTBUG-82615
Change-Id: Ie944eb1d643e7271551c9f8337609741e419e9d8
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
It appears there's a difference between the chosen macOS compiler path
in the CI versus the compiler path on my local machine.
In the CI the chosen compiler path ends up 'being /usr/bin/clang++'
whereas for me locally it's
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
For some reason the headersclean commands succeed in the CI, but
locally they fail for me saying that standard library includes can not
be found, unless an explicit sysroot flag is specified.
I assume that in the CI the '/usr/bin/clang++' compiler shim chooses some
implcit sysroot, whereas the longer Xcode compiler expects an explicit
sysroot.
It's probably also affected by the fact that in the CI we pass an
explicit CMAKE_OSX_SYSROOT to a non-standard Xcode location e.g.
/Applications/Xcode11.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
Note the '11' in the Xcode app name.
Locally I don't pass a custom CMAKE_OSX_SYSROOT, and my Xcode is
installed in a regular location e.g /Applications/Xcode.app.
The sysroot flag and path is added to regular CXX compilation rules
inside CMake's core (in cmLocalGenerator.cxx).
Reuse the same variables that CMake uses and add them to our headersclean
command rules.
Task-number: QTBUG-82615
Change-Id: Ic03ea27e39471f5fa168eb5970bf3d3f1d1be251
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Add 3 new convenience custom targets:
'qt_plugins', 'qpa_plugins' and 'qpa_default_plugins'.
Additionally, if we detect that an internal executable / test
links against Gui, add a dependency on the 'qpa_default_plugins'
custom target, so that if a developer configures Qt for the first time
and then calls ninja 'tst_foo_check', we ensure the test will launch
successfully because the default QPA plugin will also be built.
Change-Id: If6dd70844b5effdf8a293f65f8785855cc85b132
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For example, we must not prepend -l to -pthread, -framework and -lfoo.
Fixes: QTBUG-87760
Change-Id: Ie1bc7a76183c2c4980c519b5f23dde6c47ec85a9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...instead of qt-cmake-private.
Also, add ".bat" on Windows.
Change-Id: I2aa94ac76f2dadfb8e94d68b19bb379b3d45a93d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The variable to check for a Windows host system was mis-typed.
Change-Id: I25b14b80d25bfec0c1a00e99833520b6fb6a4b02
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
This makes the diff-ing of the config summary between qmake and CMake
builds correct.
Change-Id: I720b69572c23afd78e6d0bea6cdf0740980c3b36
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
In configure.json files we have inputs with dashes, e.g.
bundlex-xcb-xinput. In configure.cmake files, these are read in their
normalized form, e.g. INPUT_bundled_xcb_xinput.
Normalize the input names in QtProcessConfigureArgs.cmake like we
already do for feature names.
Change-Id: Iece414d40a0e9e2920580f2fda68e25cd32674c9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
On a mac that can build all of Qt with CMake, Ninja, and command line tools,
there should be no warning just because a build tool that
won't get used is not available.
Turn the warning into an informative message instead so that IDE
integrations (such as VSCode's CMake integration) don't flag warnings.
Change-Id: I250c0e5dd0633b36ff2b690a52ba7ce3ceb22218
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
...for QT_BUILD_TOOLS_WHEN_CROSSCOMPILING.
qt_internal_export_additional_targets_file now gets two lists of target
names when run from qt_export_tools:
- TARGETS containing actually existing targets, and
- TARGET_EXPORT_NAMES containing the target names as they appear in the
additional target info file.
Operations that require actual targets are run on the TARGETS, in the
additional target info file only TARGET_EXPORT_NAMES are written.
This distinction is required for the case where the host Qt lacks a
tool that is built in the target Qt.
Example: host Qt is built with DEVELOPER_BUILD=OFF, target Qt is built
with DEVELOPER_BUILD=ON. Then the host Qt lacks qmljs, but it is built
in the target Qt. TARGETS contains qmljs_native, and
TARGET_EXPORT_NAMES contains qmljs.
Fixes: QTBUG-87693
Change-Id: I615aed996bfcbe654274defcda8c1cb2cc4b7b4e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Do not append "/qtbase" to QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX
when doing a top-level build. The "/qtbase" suffix is already part of
this variable's content.
Fixes: QTBUG-87682
Change-Id: If1c2075dc58d4b07a4c3a1eed12cc3336c5dc8e6
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Do not print warnings for the configure arguments -commercial,
-opensource and -confirm-license. We're not removing the arguments yet
to keep existing build scripts working.
Fixes: QTBUG-86096
Change-Id: Ieb63e2f2b81c022e8559cde6c3e0be0b8ce655ca
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The use-case is relevant for other platforms as well.
Now that Qt has a module system we can also replace a lot of the
hand crafted logic for linking with simpler constructs.
Change-Id: Ib6853aaf81bfea79c31f2de741d65b4b56f23ef6
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
The Android toolchain file is now autodetected from the location of the
NDK. The NDK location can be specified by setting the CMake variable
ANDROID_NDK_ROOT. Auto-detection of the Android toolchain file is the
only purpose of this variable.
In recent Android SDK installations the path to the NDK is well-known
and can be auto-detected too. If only ANDROID_SDK_ROOT is given, we try
to detect ANDROID_NDK_ROOT first and from that the Android toolchain
file.
Adjust the build instructions in cmake/README.md, and remove the part
where we suggest to set some environment variables that are only used to
create the cmake call.
Task-number: QTBUG-87068
Change-Id: Ia0df5df7651e98979e9cead1cdae7b17ecbc4afb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We want this in order to be able to export constexpr members.
Change-Id: I33ba7964ebee54fe656df983985d8d6fa0b99358
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This needs to map to ECM_ENABLE_SANITIZERS.
Fixes: QTBUG-87316
Change-Id: I9e983728af0ba69fd428944e647f0afae8c61772
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Provide two customization points:
- optionally include a 'qt.toolchain.extra.cmake' file if it exists
and is placed next to the main generated toolchain file.
This use case is mostly for the Qt installer, so that it can create
an extra file with correct installer-provided paths, instead of
patching the toolchain file directly.
- optionally include a file passed via the command line CMake argument
'QT_TOOLCHAIN_INCLUDE_FILE'.
The use case is for application developers that might want to adjust
the toolchain file after the modifications done by the Qt installer.
These options do not replace the existing QT_CHAINLOAD_TOOLCHAIN_FILE
option, which is meant to chainload a platform specific existing
toolchain file (like Android or Emscripten).
Task-number: QTBUG-87068
Change-Id: I956949840f55742cfbd3bc8fc0bd8c6b3f774d3d
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
And wrap the various behaviors into separate functions.
Change-Id: If940351af34e445de050f2b46301de7080b1555b
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Detect an iOS build when either an -sdk option is passed
or when -xplatform macx-ios-clang is passed as a target
mkspec.
Now that CMake 3.17 is released, change the default behavior of the
iOS build to configure with simulator_and_device set to ON, like it
is with qmake.
Update the documentation regarding iOS configuration.
Change-Id: I91aaf706610b8d3c69f1ad4ba9dadee2b1e5db97
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
It appears that CMake's Xcode generator default behavior can't really
handle imported object libraries location, which Qt uses extensively
(all the qt_add_resource calls).
Specifically the project fails to configure with the following error
message:
The OBJECT library type may not be used for IMPORTED libraries under
Xcode with multiple architectures.
An issue was filed upstream at
https://gitlab.kitware.com/cmake/cmake/-/issues/21276
In the mean time, it looks like it's possible to work around the issue
by setting XCODE_EMIT_EFFECTIVE_PLATFORM_NAME global property to OFF.
This needs to be done before the very first project() call, so we do
it in the generated Qt toolchain file.
Note that the workaround only works if the CMake project is configured
with a single architecture given to CMAKE_OSX_ARCHITECTURES.
If multiple arches are given, it will fail with the same error
message.
Fixes: QTBUG-87198
Change-Id: I2556ae28b2fc2d9cfe464a5acf9c4fcbaf01b654
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>
Add an abstraction over Qt::WinMain (aka qtmain.lib) and
iOS's runtime linker entry point (_qt_main_wrapper).
The Core target will now link against the Startup target on all
platforms, instead of just WinMain on Windows.
The creation and linkage interface definition of the Startup target
is done at find_package(Qt6Core) time via the private call of
_qt_internal_setup_startup_target().
This will add automatic linkage of WinMain to executables marked with
the WIN32_EXECUTABLE property on Windows.
As well as the addition of the '-Wl,-e,_qt_main_wrapper' linker flag
when linking iOS executables.
Qt users can opt out of this behavior by either setting the
QT_NO_LINK_QTMAIN property or variable. This is in line with
Qt 5 behavior.
Task-number: QTBUG-87060
Change-Id: I7d5e9f1be0e402cf8e67e6f55bfd285f9e6b04f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
As there is no other way of obtaining information about Qt's paths at the
moment, windeployqt is still querying qmake for these information. For a
cross compiled Qt, the proper target mkspec has to be set in this case.
Change-Id: I0b7b7719c9055d432576185ac4f7572a5ba1dd6b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When loading the tool packages from the host Qt we must ignore
QT_NO_CREATE_TARGETS. Otherwise tool targets like Qt6::moc are not
available.
Task-number: QTBUG-85080
Change-Id: I2c8c8e68863f28a4f1d9cd2f70090455c49d8df2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Tests were never built by default, except for -developer-build.
Examples were build, but aren't anymore by default if you
run cmake directly.
Let the default be figured out by cmake, and only set
BUILD_EXAMPLES and BUILD_TESTING if the user has
expicitly passed them via -make or -nomake.
Task-number: QTBUG-87217
Change-Id: I37321d96cc1e9e184a711a858c860b0205d5b74f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
3.17.0 is released since a while. ANyhow, the requirement for
3.17 for simulator_and_device builds is already mentioned
at the start.
Change-Id: Ic8813bb60b010feb97a47b878124c3e75658813d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
All usages should be replaced with qt_internal_add_executable instead.
This should fix configuration failure of benchmarks and manual tests.
Amends e0c62a48b8
Task-number: QTBUG-86815
Change-Id: I0791d849998ed9517e32f699d843367949b97cb9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This variable can be set when using qt-cmake[-private] to override the
CMake toolchain file that is chainloaded by Qt's toolchain file.
Task-number: QTBUG-87068
Change-Id: Id529408381e4174becda1ba07a489535c8cf1314
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
These were introduced in
675805e9eb and
b9c85d6b0e
They should be exported if they were set.
Change-Id: Ieec565980ba148f675f84dcdd7c19894e349085f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The value is used by mkspecs/features/mac/default_post.prf and
ultimately by xcodebuild to decide which arch and SDK to build
against.
For a simulator_and_device build, no value needs to be set as far as
I can see.
Task-number: QTBUG-87218
Change-Id: I41992bec6b16aadfd87c3f7c10653a6094e76d3e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If no mkspec is provided, we default to the macx-clang-ios mkspec when
building for iOS. This ensures that the wrapper qmake script is usable
for building iOS apps with qmake.
Task-number: QTBUG-87218
Change-Id: Ib02b580c8382b04455c9f820163062591d14a15b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Introduce a new feature called 'FEATURE_msvc_obj_debug_info' which
should allow usage of sccache for Windows MSVC configs.
Enabling the feature will replace the default '/Zi' compile flag
that CMake sets in Windows-MSVC.cmake with '/Z7'.
This ensures that the debug info is placed into the compiled object
file instead of placing it in the compilation .pdb file via
mspdbsrv.exe.
The final pdb file will still be created for shared libraries and
executables due to the linker '/debug' flag.
Static libraries will not have a .pdb file, instead the debug info
being embeeded in the .lib file.
The downsides of using '/Z7' are more disk space usage, slower
link times, more memory used for linking because the linker needs
to deal with more symbols.
The upside is that caching each indepedent cl.exe call is possible.
This is what Chromium uses with goma, and Firefox with sccache.
We're not enabling the feature by default to allow easier
testing (and switching it off) in the CI if it proves not to be
feasible.
It will probably have to be disabled at least for building
qtwebengine due to high memory requirements.
Task-number: QTQAINFRA-3934
Change-Id: I89e0e57995e938a780be318d1faec700194aa93f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Enabling it will force usage of '-O3' flag when building Qt.
If the platform has no '-O3' flag, use '-O2' as a fallback.
Task-number: QTBUG-86866
Change-Id: If13f7de954ba5c01dc9634f06a85529828fe90a9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Introduce a bunch of helper functions to manipulate compiler
flags and linker flags for the
CMAKE_<LANG>_FLAGS_<CONFIG>
and
CMAKE_<LINK_TYPE>_LINKER_FLAGS_<CONFIG>
CMake variables.
These variables can be assigned and modified either in the cache
or for a specific subdirectory scope, which will apply the flags
only to targets in that scope.
Add qt_internal_add_optimize_full_flags() function which mimics
qmake's CONFIG += optimize_full behavior.
Calling it will force usage of the '-O3' optimization flag on supported
platforms (falling back '-O2' where not supported).
Use the function for the Core and Gui subdirectories, to enable full
optimization for the respective Qt modules as it is done in the qmake
projects.
To ensure that the global qmake-like compiler flags are assigned
eveywhere,
qt_internal_set_up_config_optimizations_like_in_qmake() needs
to be called after Qt global features like optimize_size and
optimize_full are available.
This means that qtbase and its standalone tests need some special
handling in regards to when to call that function.
Task-number: QTBUG-86866
Change-Id: Ic7ac23de0265561cb06a0ba55089b6c0d3347441
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
Implement the last remaining Android-related configure options for the
CMake build.
Print warnings for options that have no equivalent in the CMake build.
Let -android-ndk automatically deduce the CMake toolchain file, and
error out if that fails with a hint how to fix the situation.
Task-number: QTBUG-85373
Change-Id: I8399e5334ae0f1f6634e381775a308d34f7c482b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qtConfAddWarning was missing, despite being used.
All of the three qtConfAdd* functions take multiple parameters and pass
them to the CMake's message() function.
Change-Id: I1fad46c6fd00b2e733b32cda482bbf1341ffc63f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This option maps to FEATURE_reduce_exports. The feature is on by
default, except for MSVC. The reduce_exports configure test is not used
in the CMake build.
The <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN target
properties are now explicitly initialized in the
qt_set_common_target_properties function, because we don't have access
to the feature in QtSetup.cmake where the CMAKE_<LANG>_VISIBILITY_PRESET
variables were set before.
Task-number: QTBUG-85373
Change-Id: I378453f0e0665731970016170302871e20ceb4e2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add some missing versionless functions.
Rename some functions that are not meant to be public API, and their
usages.
Task-number: QTBUG-86827
Change-Id: Ifb66c04cd7598d83fe80c01a92ab2d269ebaf396
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The CMake build uses the WARNINGS_ARE_ERRORS variable, and the feature
warnings_are_errors exists only in the qmake build.
Change-Id: I1e548b30b210b3dd1b2f23041d490a981312f4ba
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
HostInfo is used in places whenever QT_HOST_PATH is set, regardless
whether CMAKE_CROSSCOMPILING is set or not. Make sure that HostInfo
is available when QT_HOST_PATH is set.
Change-Id: I39763a61d77e97dc9c4cc3875bce4deb942f870a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add qt6_android_get_sdk_build_tools_revision() function to get the
Android SDK build tools revision, the logic is moved from
QtPlatformAndroid to Qt6AndroidMacros. The update QtPlatformAndroid
header comments.
Task-number: QTBUG-85982
Change-Id: If3e5b46fa583f929a24794792c9d5a52beb83990
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make name format of QT_ANDROID_DEPLOYMENT_SETTINGS_FILE consistent with
qmake, that is android-${target}-deployment-settings.json.
Task-number: QTCREATORBUG-24678
Change-Id: I2bdb056cf7a82fd83aaf658f3a405a0c9ef05756
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This ensures that we have the configuration-independent IMPORTED_*
properties set on tools.
Fixes: QTBUG-86893
Change-Id: I2b772c21341e6e4631379d4a5a99580ec96909ed
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To provide the IMPORTED_LOCATION target property we must write
the *AdditionalTargetInfo.cmake file for all debug-only builds, not only
the ones containing a release configuration.
Task-number: QTBUG-86893
Change-Id: I9ecd01483660f434a3f1ea12fa2af756cdcf9932
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It causes issues in our Windows CI, because the strawberry perl
pkg-config is found. And even that one is unusable, due to a bug in
CMake which is tracked at
https://gitlab.kitware.com/cmake/cmake/-/issues/21239
Change-Id: I58816195d35459e8a44c923399c35a4956c222a2
Reviewed-by: Simon Hausmann <hausmann@gmail.com>
By default, when using the Qt6 CMake package to look for components,
the find_package() calls for the components use NO_DEFAULT_PATH to
ensure that CMake doesn't accidentally find system (distro) packages.
Instead we limit the paths to one level up from where the Qt6 package
is.
Unfortunately that doesn't quite work for finding Qt packages that
might have been installed into a different prefix than where the main
Qt prefix is.
This happens when Qt addons are built by Conan, and installed into
a separate prefix.
To allow calls like find_package(Qt6 COMPONENTS ConanAddon) to work
in a scenario as described above, introduce a new variable called
QT_ADDITIONAL_PACKAGES_PREFIX_PATH which can be used to specify
additional paths where Qt CMake packages should be found.
This is similar to previously introduced QT_EXAMPLES_CMAKE_PREFIX_PATH
variable which was meant for a similar case, but only for examples.
Additionally, allow disabling the NO_DEFAULT_PATH option by setting
the QT_DISABLE_NO_DEFAULT_PATH_IN_QT_PACKAGES cache variable to TRUE.
This would allow regular usage of CMAKE_PREFIX_PATH to work, at the
risk that system Qt CMake packages might be found.
Augments 5cd4001bf2
and ffe0889413.
Fixes: QTBUG-86882
Change-Id: Ia8e060cbba6d2a10c3d63d81892f2c71e4236a9a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Make the use of ANDROID_SDK_ROOT consistent.
Task-number: QTCREATORBUG-24678
Change-Id: If967bdc4d252996098fa210cf38429fe075eacb1
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
Consider a Qt module with a 3rdparty library target in
PRIVATE_MODULE_INTERFACE, e.g. XKB::XKB in Qt6::GuiPrivate. Consumers of
GuiPrivate automatically depend on XKB::XKB. In order to do that they
must find_package(XKB ...). As all find_package calls for GuiPrivate are
in the same place as the ones for Gui, this package must be marked as
optional. Otherwise all consumers of Qt6::Gui would have to have the
xkbcommon package installed too.
This patch exports find_package calls for every 3rdparty public
dependency of private modules and marks them as optional.
Change-Id: Ia1eeb09c29927fb6634ef08b477684ed6f123267
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Apparently the combination of the --no-undefined linker flag together
with ASAN when building on Linux with Clang does not work.
Disable --no-undefined flag in such a scenario. Note that linux-clang
mkspec doesn't add that flag at all, which is why asan builds work
there.
Change-Id: I6167c757ce4be5d2263311bc84e5fb445b0f7c2d
Fixes: QTBUG-86879
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
Android minimum API level for Qt 6 is 23, this reflects that to some
instances that still mention 21.
Change-Id: I996f3ed3af14dca114129351d6ea06afcb8f45f5
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
00a1e5da7e wrongfully added parts of
QtPlatformAndroid.cmake which were removed in
32121e9882. This removed the part in
question again
Change-Id: Ie18968e6a165f52c68f4941ced6add266985bc48
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>
When re-doing in a top-level build, we did not read the config.opt file
from the top-level directory.
Also, the config.opt file should not contain the -top-level argument.
This is an internal option, and on Windows, it was already missing. The
information whether we're doing a top-level build is now passed in the
CMake variable TOP_LEVEL.
Change-Id: Iaecd7306a4b6d9ad494684c201cf12f8e74d684b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Having ${QT_BUILD_DIR}/include as include path is not enough for
modules outside of qtbase. They also need to pick up headers from e.g.
Qt Core, which are available only in "${CMAKE_INSTALL_PREFIX}/include"
This amends db21bad936
Fixes: QTBUG-82615
Change-Id: Ib003a66ce039bf1ab6e21a3b1cd86923207eb3db
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We must use the LIBRT location instead of LIBRT_FOUND which is not set anywhere.
I failed to replace this one in my previous patch.
Change-Id: I6e2df82c31e29018d99afec1eecfb80a321fddd4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt_add_test supports now QT_TEST_SERVER_LIST, which will add the test
servers as docker test fixtures.
The docker server will be started before the test is run, and stopped
after the test is run.
Running the tests in parallel is not supported.
Docker tests are currently only supported on Linux hosts.
Task-number: QTBUG-85034
Change-Id: If3cefe05c5dec19c14b05d2fa8b01a0b6d95e259
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Avoids a linking error when the library is not found as
find_library sets GLESv2_LIBRARY to GLESv2-NOTFOUND
Change-Id: I7ddc15483276e0be0c78b67b760c4d9188758270
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
