Parse the -qpa configure argument as list and translate it to the
QT_QPA_PLATFORMS cmake variable. This variable is new to the Qt build
procedure. The QT_QPA_DEFAULT_PLATFORM variable supposed to get
multiple values, but this didn't work at all, since the variable value
then was used in the compile definition that is expected to be a single
value QPA platfrom definition. This inconsistency forced to introduce
a new variable.
The QT_QPA_DEFAULT_PLATFORM variable now controls the first-choice QPA
plugin for the GUI applications. The new configure argument
-default-qpa is now translated to the QT_QPA_DEFAULT_PLATFORM variable
instead the of -qpa one. The -qpa configure argument is now translated
to the QT_QPA_PLATFORMS variable, which is new one as well. The
variable contains the list of QPA plugins that are "default" for this
Qt configuration. The meaning of the "default" plugins is related to
the DEFAULT_IF argument of qt_internal_add_plugin command. Plugins
that are listed in the QT_QPA_PLATFORMS variable will be treated as
default by the build system and will be deployed within user
applications when using deployment API or linked statically when using
static Qt.
The QT_QPA_DEFAULT_PLATFORM falls back to the QT_QPA_PLATFORMS first
value in the list if it's not set explicitly and either
'-DQT_QPA_PLATFORMS' or '-qpa' arguments are specified.
[ChangeLog][CMake] Added QT_QPA_PLATFORMS variable which controls the
list of QPA plugins that will be deployed within the applications by
default.
[ChangeLog][CMake] The '-qpa' configure argument now is mapped to the
QT_QPA_PLATFORMS variable and has different functionality. It doesn't
control the platform plugin that the GUI application is using by
default, but controls the list of QPA plugins that will be deployed
within the applications by default.
[ChangeLog][CMake] Added '-default-qpa' argument which replaces the
'-qpa' one. The argument is translated to the QT_DEFAULT_QPA_PLATFORM
CMake variable and selects the default platform that should be used
by GUI application if QT_QPA_PLATFORM environment variable is not set.
Task-number: QTBUG-124265
Task-number: QTBUG-87805
Task-number: QTBUG-124449
Change-Id: Ibcebaccc535aaed6374f15ccfeddb3e6128f5ce0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We never properly handled double-hyphen arguments like --list-features.
However --developer-build worked by accident, because it did set
INPUT_developer_build implicitly.
Now, we don't automagically translate INPUT_foo to FEATURE_foo anymore,
and --developer-build stopped working.
Fix this by consistently handling -foo and --foo arguments.
Change-Id: Ibf32979b419c28e0a8e1f810f03ae3f295b14c69
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
'headersclean' shoudn't be a feature. The respective flag should behave
like command-line switch that affects the only repo that it was passed
for. This also avoids propagating of the headersclean feature between
the different repos when qtbase was built with the headerclean enabled.
Fixes: QTBUG-121722
Change-Id: I304cbc980b06030513c015a2016678a6a0965fed
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Inline namespaces serve the purpose for which the original
-qtnamespace option was added and allow for macro simplification (no
need for any using directives). This makes it possible to use
namespaced builds of Qt also for Qt for Python and similar use cases
which have issues with the additional namespace.
[ChangeLog][QtCore] It is now possible to use an inline namespace for
-qtnamespace (option -qtinlinenamespace).
Task-number: PYSIDE-2590
Change-Id: Ia0cecf041321933a2e02d1fd8ae0e9cda699cd1e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
These options are declared with TYPE enum and a MAPPING that's supposed
to control the feature 'system-zlib' or 'system-sqlite'. Since only
inputs of type boolean control features now, we need to somehow declare
that this non-boolean input controls a feature.
We do this by adding the keyword CONTROLS_FEATURE to
qt_commandline_option. For example,
qt_commandline_option(zlib
CONTROLS_FEATURE
TYPE enum
NAME system-zlib
MAPPING system yes qt no
)
declares
- commandline option "zlib" sets the input "system-zlib",
because of the "NAME system-zlib" argument
- accepted input values are "system" and "qt", because
we have "TYPE enum" and the odd values of MAPPING
- those values are translated to yes/no, because of the
even values of MAPPING
- CONTROLS_FEATURE forces the translated input's type
to boolean, and with that it will set the corresponding
feature 'system-zlib'
Luckily, only qtbase has command line options with MAPPING declared.
Change-Id: I82d06cec43ece3b002c8f5dd414c68dc730909af
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This amends commit 110f656da9e9b2511c89679e79b197a3e7b07393.
Command line options with a TYPE that denotes a custom command line
argument handler cannot set a feature "foo" anymore by just setting
INPUT_foo to "yes". Instead, they must use the newly introduced
functions qtConfCommandlineEnableFeature and
qtConfCommandlineDisableFeature.
These functions will set INPUT_foo and augment the input with the
information "this input is of boolean type". This information is used
when deciding whether to use this input as feature switch.
Change-Id: I83c691cc57424159148f059c2a1c8cd72e39ee63
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We don't need to deal with the input arguments to configure. We
can instead look at QT_QMAKE_TARGET_MKSPEC, like we do when we
auto detect other platforms. This handles both the -xplatform
and the -platform arguments.
Change-Id: I8d987d23e16bfa106833d521f67e8b5a931d9169
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The -sdk argument is documented as:
Build Qt using Apple provided SDK <sdk>. The argument should be
one of the available SDKs as listed by 'xcodebuild -showsdks'.
[ChangeLog][configure] The -sdk argument no longer auto-enables
the macx-ios-clang makespec. Pass -xplatform macx-ios-clang to
explicitly build Qt for iOS.
Change-Id: Ia4074015aba2c8296a65534c38eb2f06db32f286
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The SDK is relevant for all Apple systems, including macOS, iOS, tvOS,
watchOS, and visionOS.
We still pick up -DQT_UIKIT_SDK for iOS for compatibility.
[ChangeLog][CMake] The -sdk configure argument now maps
to the QT_APPLE_SDK CMake variable. QT_UIKIT_SDK is still
supported for iOS builds for compatibility.
Change-Id: I983a2f23c2414eb73cd35bb83738088defb45cbd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This amends commit be009c6857dc75c0bdf789c4ac9323f0cf1fd9e6.
The configure option -no-opengl was mistakenly translated to the CMake
argument -DFEATURE_opengl=no. The command line option "opengl" however
is defined as
qt_commandline_option(opengl
TYPE optionalString
VALUES no yes desktop es2 dynamic
)
which is not boolean. And only boolean command-line options may
automagically control features of the same name. It just happens that
the values "no" and "yes" look boolean.
Setting FEATURE_opengl instead of INPUT_opengl broke feature conditions
that check the INPUT_opengl value.
Fix this by checking the type of the corresponding command line option
instead of guessing the type from the INPUT_* value.
An option (e.g. force-asserts) can be diverted to a differently named
input (e.g. force_asserts) with the NAME argument of
qt_commandline_option. In this case, we cannot deduce the option name
from the input's name. To handle this, we store the input's type in
commandline_input_${name}_type and read it when translating feature
values.
Fixes: QTBUG-122914
Change-Id: Ibb4b0633b6635bd2ef6f26ed8f4b19d239bf5854
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Inputs (in the sense of configure commandline options) are now
translated to -DFEATURE_foo=ON/OFF if the input name matches a feature
name. This is going to replace more complicated logic in our feature
evaluation.
Task-number: QTBUG-120529
Change-Id: I3ef45cd0e0a1462c53543cd2152eaf7f94318d9d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Directly set the feature variable instead of the INPUT_* variable.
The magic translation from INPUT_* to FEATURE_* is removed in a
subsequent commit.
Change-Id: I8156a20e9af6883783c9a7fa6b4f591d7a2f587c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
We now convert the configure arguments -feature-foo and -no-feature-foo
to the CMake arguments -DFEATURE_foo=ON and -DFEATURE_foo=OFF. This is
done, because the former behavior was surprising, and it allows us to
remove quite some code that was needed to calculate feature values from
INPUT_foo and FEATURE_foo.
Task-number: QTBUG-120529
Change-Id: I94f8eb4adbbcaa1090aedce6e711012781c62a3c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
When using configure arguments like -system-libpng then we saw lines
like this in configure's output:
opt: libpng val: system
This is a left-over debug message which went unnoticed for a long time.
This patch removes it.
Change-Id: Ic655fbc9aedb887743206fdfb344bf2f5eca7a12
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Features enable code coverage collecting using the gcov tool. The
resulting reports can then be post-processed by lcov or similar tools.
[ChangeLog][CMake][Coverage] Added the coverage configuration argument.
The only supported coverage tool at the moment is gcov. The argument
requires Qt is built in Debug otherwise setting the argument leads to
the configuration error. Typical usage:
<...>/configure -developer-build -coverage gcov
Task-number: QTBUG-86223
Change-Id: I39b2061f544997a7c4fe6f4d135c0ab447f15a17
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Just some help to users, so they can spot the allowed values without
looking into docs.
Pick-to: 6.6
Change-Id: I22ad9533104949286de447a05a6e875e8d933bf6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To be able to reconfigure Qt with modified feature values using the
configure script, and take into account INPUT_foo values, we need to
ignore FEATURE_foo values. But we can't always ignore FEATURE_foo
values, because users might want to toggle them by editing
CMakeCache.txt or using an IDE.
What we can do is tell CMake we are configuring via the configure
script, in which case we can mostly be sure that any passed
INPUT_foo values should have higher priority than pre-cached
FEATURE_foo values.
We also need to remove all the cached INPUT_foo variables after they
have been used for feature computation, so that subsequent
reconfigurations where an INPUT_foo is not passed anymore, doesn't
cause a feature to accidentally reuse the previous (stale) value.
Pass -DQT_INTERNAL_CALLED_FROM_CONFIGURE=TRUE to CMake when configuring
via the configure script, and use that as a marker to make INPUT_foo
values have a higher priority.
This needs to be done centrally in qt_evaluate_feature and also in a
few more locations where we check INPUT_ values, like the developer
build and pkgconfig features.
Because QT_INTERNAL_CALLED_FROM_CONFIGURE would become a cached
variable, we want to remove it at the end of the configuration phase,
so that future 'cmake .' reconfigurations are not considered to be done
via configure.
To do that, we unset it right at the end of
qt_build_repo_end in a per-repo build, and in the final
qt_print_build_instructions call in a top-level build.
The latter needs a cleaner fix in follow up commits in qt5.git and
qtbase.
Pick-to: 6.6
Task-number: QTBUG-112957
Change-Id: I3fd338092041ef09e3f5a4dfbaf61da5deea0514
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
In Qt 5 times, if Qt was configured with -make examples, running
make install would not only build and install the example binaries,
but would also install the example sources into the prefix.
Installation of example sources was not implemented when the Qt 6
build system has switched to using CMake.
There is still a use case for it though, mainly for Qt Creator, which
only shows the examples of a Qt kit if the sources are available.
In contrast to Qt 5, in Qt 6 we will not install example sources
by default. It will be opt in.
To enable installation of examples sources, configure with
configure -make examples -install-examples-sources
or
cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON
The -make examples part is required, otherwise
-install-examples-sources has no effect.
All example sources can be installed by calling
cmake --install . --component examples_sources
in the qt repo build directory.
In a top-level build, per-repo installation can be done using
cmake --install . --component examples_sources_<repo_name>
where repo_name could be 'qtbase'.
A single example's source can be installed by calling
cmake --install . --component examples_sources_<subdir_name>
where subdir_name is the subdirectory name of the example, e.g.
'gallery'.
Implement installation of example sources by hooking into the
qt_internal_add_example command.
This means that all examples in all repos need to be added via
qt_internal_add_example instead of add_subdirectory, to ensure the
sources are installed. The majority of repos already use it.
For testing purposes one can configure with
-DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON
-DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation
of examples sources without building them.
Take into account an additional variable called
QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of
example sources into a location different from the example binaries.
As a cleanup, the NAME option that could previously be passed to
qt_internal_add_example_external_project has been removed.
That's because it's never used anywhere and could not have worked
anyway because qt_internal_add_example_in_tree never handled it.
Pick-to: 6.6
Fixes: QTBUG-112135
Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
If '-G<generator type>' is passed to configure script we should respect
this argument but not override it by the autodetected generator type.
'-cmake-generator' option will still have higher priority, but if
generator is set using CMake argument it will not be auto-detected by
other build config specific options, like '-debug-and-release'.
Change-Id: I75b49e33fa717f90bbd74045948fccb9f5350e8d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
I added the ability to use `-no-unity-build`, and included the
batch size in the config.summary as well. In addition, qt_feature is not
being used for `-unity-build` anymore.
Pick-to: 6.5 6.6
Change-Id: I4a10e03d3505336d2256280ed2854ec0425df47f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Vcpkg detection is enabled by default, but we did not have a flag to
disable it, and it was not showing up in config.summary either. By
adding a -vcpkg flag, we get to use `-no-vcpkg` when necessary, as well
as adding an entry to config summary indicating whether vcpkg is in use
or not. Besides `-no-vcpkg`, one can pass `-DQT_USE_VCPKG=OFF` to cmake
command in order to disable the automatic vcpkg detection/integration.
[ChangeLog][configure] vcpkg detection, and integration can be disabled
by passing the -no-vcpkg flag to the configure command, or by passing
`-DQT_USE_VCPKG=OFF` to the cmake command.
Pick-to: 6.6
Change-Id: Ide8da70a7b473ec23995104d162356e75e6d1240
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Accounting for the case where `MODULE_ROOT` is set to `.` which then
makes the `get_filename_component` command to return an empty string;
consequently, we cannot find the `config_file.txt`, and cannot process
the features correctly.
Amend f4bf7982a679312146546fabfb086e801c2bbc37
Pick-to: 6.5 6.6
Fixes: QTBUG-114085
Change-Id: I55c7529be6caba4691adec80efca8021bd03c500
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The `-sysroot` does not have any effect, and it can be removed.
I added a warning in case someone is still using it.
[ChangeLog][configure] The -sysroot option was removed. Use
CMAKE_SYSROOT or CMAKE_TOOLCHAIN_FILE instead.
Task-number: QTBUG-112951
Change-Id: Ib180b891ca8228ef1ebf9be43f2f6b8b5b5b0ee7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In unity build, when calling qt-configure-module.bat, if we don't pass
an absolute path, CMake will not be able to resolve the header paths in
`*_cxx.cxx` unity headers. So far, this only happens on Windows/LLVM,
and it is probably an oversight on CMake side, as passing a path without
drive letter is perfectly fine in most cases, and CMake can handle it.
We don't need the TO_CMAKE_PATH, as `get_filename_component` also does
the transformation.
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: I474750af13291cbf1a46a12be5fc4a0f6e88accf
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If -unity-build-batch-size is not given, we default to CMake's default
which is 8. In QtSetup.cmake, we explicitly set the default to avoid
having it set to OFF in case it is missing, just to make sure that we
don't get any unintended behavior.
Task-number: QTBUG-109394
Change-Id: I19849e9baa507b64fb23847c740e20a7adc61b8f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In the case of re-doing, `configure` and `configure.bat` pass an extra
parameter to the `QtProcessConfigureArgs.cmake`. As a result, CMake
removes CMakeCache.txt and CMakeFiles/ before the reconfiguration. If
the user is using CMake 3.24 or newer, this is achieved by passing
the `--fresh` option to CMake call. In older CMake(s), CMakeCache.txt
and CMakeFiles/ found in CMAKE_BINARY_DIR will be removed using a
file(REMOVE_RECURSIVE call.
[ChangeLog] The -redo option now additionally removes existing
CMakeCache.txt file, and CMakeFiles/ directory, and recreates them from
scratch.
Task-number: QTBUG-108287
Change-Id: I11a5c8f9df1247d11eb7097552e6764463583346
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And also teach CMake to treat it properly instead of hardcoding the
version number.
[ChangeLog][Build System] The configure script now accepts a new
parameter -disable-deprecated-up-to which is used to remove all
deprecated code from API and ABI while building the libraries.
The version number must be specified in a hex format.
For example, it can be used like this:
/path/to/qt/configure -disable-deprecated-up-to 0x060500
to remove all code deprecated in Qt 6.5.0 or earlier releases.
Task-number: QTBUG-101510
Change-Id: I557cf83e29b867fa1052bb097985e144b5eaf34d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
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>
Raise the CMake log level to STATUS when the 'verbose' argument is
passed to the configure script.
Change-Id: I736d95ab66b115f8416eec7f9e2ee96d1580c78d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
ANDROID_NATIVE_API_LEVEL is an alias for ANDROID_PLATFORM and the
Android's CMake docs [1] uses directly ANDROID_PLATFORM so let's use
that as well. Also, NDK r23b seems to have removed the part of code from
android.toolchain.cmake that handles ANDROID_NATIVE_API_LEVEL to set
the correct value to ANDROID_PLATFORM.
With this change, CMake will pass the value from the configure argument
-android-ndk-platform as -DANDROID_PLATFORM instead of
-DANDROID_NATIVE_API_LEVEL. Otherwise, if if -DANDROID_NATIVE_API_LEVEL
is passed directly to CMake, it should work as before.
[1] https://developer.android.com/ndk/guides/cmake#build-command
Pick-to: 6.3
Task-number: QTQAINFRA-4837
Change-Id: I5c21af53ac91e11a27c4b033313d22d1115c1abc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It broke drive-less (no C:\ prefix) paths passed to configure.
Invoking configure on Windows with the following args
qtbase/configure --
-DCMAKE_INSTALL_PREFIX=\Users\qt\work\install
called CMake with
-DCMAKE_INSTALL_PREFIX=\\Users\\qt\\work\\install
saying
Qt will be installed into '//Users/qt/work/install'
and while the build succeeded, installation would fail with
CMake Error at cmake_install.cmake:41 (file):
file cannot create directory:
//Users/qt/work/install/lib/cmake/Qt6BuildInternals. Maybe need
administrative privileges.
Note the double slash in the beginning is likely interpreted as a
Windows share URI / UNC path.
The same would happen when passing -prefix '\Users\qt\work\install'
As a reminder, we want to support drive-less prefix paths because
that's what Qt's Coin CI uses passes to ensure DESTDIR installation
works correctly.
Amends cb7f4030bc89471aa6489be60ac1c728a3dfd06b
Pick-to: 6.2 6.3
Fixes: QTBUG-94366
Change-Id: I9267b6f784babfbdaeafc65267ba96c75fa24112
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Introduce a new -no-prefix option that can be used to build Qt without
having to install it.
Currently, -no-prefix is already implied by -developer-build, but
-developer-build also implies -warnings-are-errors and
-feature-private-tests, which not everyone might want to use.
Some Qt builders likely use -developer-build for the no-prefix
behavior, hence we introduce a standalone -no-prefix option to offer
a nicer user experience without -Werror and friends.
Previously it was possible to achieve the same by specifying
-prefix $PWD, but that relies on $PWD expanding property in the used
shell.
The new -no-prefix doesn't depend on the type of the shell and
is shorter to type.
Internally this gets passed by configure as -DINPUT_no_prefix=yes to
CMake, and transformed into a -DQT_FEATURE_no_prefix=ON feature.
The feature also gets automatically auto-detected to ON if
developer-build is set, -prefix is either unset or $PWD.
CMake code should still query QT_WILL_INSTALL to decide whether
files need to be installed or not.
As a drive-by, we now also export QT_FEATURE_developer_build to
be available for querying during configuration of other repos
(previously it was only possible to query FEATURE_developer_build).
Pick-to: 6.2 6.3
Change-Id: Iaa6c8d8ae2b736282e9949d2a5d7f412e290a253
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Yield a warning instead of an error that -skip and -submodules have
no effect in a per-repo build.
Amends acaba632605ac22aa3da4c3cf8e5891cb9cde657
Adjusts to 11ae0e772cccd3028771c1380f077c605224cc19
Pick-to: 6.2 6.3
Change-Id: Ic26b0ba29e48be5162f13ad75308f8358d8878e3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Specifying the options would do nothing, so it's better to error out
early in case the developer accidentally added them.
Pick-to: 6.2 6.3
Change-Id: Ia516468a22c3c48e9e84dc78e522e8870186d96b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The option is used to specify a list of Qt repos (git submodules)
that should be included in the configuration of a top-level Qt build.
The option takes a comma-separated list of qt submodule names e.g.
'qtbase,qtsvg,qtdeclarative'
It can also take a single value like 'qtbase' or 'qtquick3d'.
Each specified submodule and all of its transitive dependencies will
be included when configuring the top-level Qt build (assuming that the
submodules have previously been already checked out).
Any missing submodules or dependencies will not be automatically
checked out, but rather skipped. This can result in a failed
configuration if a required submodule is missing.
If some optional transitive submodule dependency is not desired in the
build, you can combine the -submodules option together with -skip
options.
E.g. configuring with
-submodules qtdoc,qtnetworkauth -skip qtmultimedia,qtimageformats
will result in a top-level build with the following submodules:
- qtbase (common dependency)
- qttools (dependency of qtdoc)
- qtactiveqt dependency of qttools)
- qshadertools (dependency of qtdeclarative)
- qtdeclarative (explicit)
- qtnetworkauth (explicit)
- qtdoc (explicit)
Pick-to: 6.2 6.3
Fixes: QTBUG-100388
Change-Id: Ie8c47cfd1d1e0e44a27260bf9ddf968531cc1cc0
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This makes skipping a list of submodules more concise.
e.g. instead of passing
-skip qtsvg -skip qtimageformats -skip qtmultimedia
pass
-skip qtsvg,qtimageformats,qtmultimedia
Pick-to: 6.2 6.3
Change-Id: I6a48828b2fd7cec9f6e19988f7b4033333768abb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously we passed flags like -ld-fuse=lld only to compile
calls, but not to the link call of a compile test project.
Make sure to pass it to the link call instead by using
check_cxx_source_compiles + CMAKE_REQUIRED_LINK_OPTIONS
instead of
check_cxx_compiler_flag.
Note the flag that is passed is still via passed via the
compiler launcher and not directly to the linker.
Remove duplicate flag handling code.
Pick-to: 6.2 6.3
Change-Id: I1bf90573904a9df83240b6debfee3cc9e425c6bb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This amends commit c5409964b0c627b25131c73f95794314feb51b5d.
When detecting a variable assignment, we must ignore arguments that
start with a dash. Otherwise, arguments like --prefix=~/Qt are ignored.
Change-Id: I3b143113b94ca0d8af92679c1f567fbcec298349
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's now possible to call configure with arbitrary variable assignments
"FOO=BAR" that get passed as "-DFOO=BAR" to CMake. There is no error
anymore for unknown variables. CMake already warns about those:
"Manually-specified variables were not used by the project: FOO".
[ChangeLog][configure] Users can directly assign CMake variables with
configure, for example "configure CMAKE_CXX_COMPILE=clang++-11".
Fixes: QTBUG-88210
Change-Id: Ib15e63a895df717919dd2b6623fa4d284209776f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The function qt_commandline_assignment and everything related to it is
removed from configure. It was only used in qtbase, and all usage has
been removed.
More general variable assignments will be added in a subsequent commit.
Task-number: QTBUG-88210
Change-Id: I7cfa782e89914f2b0dc0277c46e425c8a825557e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This hasn't worked for some time. It's not in our CI and I don't think
it was working at all. When I tried to build it, I ran into several
problems with C++17 and an Internal Compiler Error I did not have any
interest in working around.
After discussing with the Intel compiler team, it was decided that
fixing those issues in the old compiler is not going to happen. Instead,
their recommendation is to adopt the new LLVM-based compiler, which
the last commit added support for.
This commit does not remove qmake support for the old ICC. It's possible
someone is using qmake with a non-Qt6 project and ICC.
Change-Id: Icb2516126f674e7b8bb3fffd16ad6350ddbd49e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Now it's possible to display a configure help screen per module with
qt-configure-module <module-source-dir> -help
Pick-to: 6.2
Fixes: QTBUG-95943
Change-Id: I7d26006246af4b38b5a2ec6deca3f45c5313afec
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The following host-related configure options were unsupported since Qt
6.0 and are now completely removed:
-hostprefix
-external-hostbindir
-host*dir (except -hostdatadir)
-android-ndk-host
Pick-to: 6.2
Change-Id: Ib69d90c40ef546f61bf87b1f443eb9d10f7a5a21
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Ensure that Qt user projects build with sanitizer flags if Qt was
configured with any of the sanitizers enabled.
To compile Qt with sanitizer support enable any of Qt sanitizer
features.
Passing -DECM_ENABLE_SANITIZERS=address to CMake is NOT supported
anymore.
When configuring Qt using CMake directly, pass
-DFEATURE_sanitizer_address=ON
-DFEATURE_sanitizer_undefined=ON
instead of
-DECM_ENABLE_SANITIZERS=address;undefined
When configuring Qt with the configure script pass
-sanitize address -sanitize undefined
as usual.
QtConfig.cmake now records the sanitizer options that should be
enabled for all consuming projects based on the enabled Qt features.
This applies to internal Qt builds as well as well as tests an
examples.
The recorded sanitizer options are assigned to the ECM_ENABLE_SANITIZERS
variable in the directory scope where find_package(Qt6) is called.
The ECMEnableSanitizers module is included to add the necessary flags to
all targets in that directory scope or its children.
This behavior can be opted out by setting the
QT_NO_ADD_SANITIZER_OPTIONS variable in projects that use Qt and might
be handling sanitizer options differently.
Amends 7e03bc39b8bcdaa4e83e72ac99e117561c124951
Pick-to: 6.2
Fixes: QTBUG-87989
Task-number: QTBUG-92083
Change-Id: I2e3371147277bdf8f55a39abaa34478dea4853a6
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Automatically set compilers based on old mkspec style target
Pick-to: 6.2
Change-Id: I80404376964a85c6b519657c054d008da47aed91
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
