When 2cf66d49ef926ee53b6c394d8be0b8e8bcf148e8 removed support for
c++14, it incorrectly also removed support for explicitly setting the
default, C++17. This broke build scripts for no good reason, and made
it impossible to undo an earlier -c++std c++20 again.
Accept C++17 and C++1z again, as an explicit disabler for C++20 and
C++23 features.
Amends 2cf66d49ef926ee53b6c394d8be0b8e8bcf148e8.
Fixes: QTBUG-125015
Change-Id: I99b80cd5f41fa5a23259630eae85ef807982f526
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 68e6406623afe5aaaa79e116cbd6b07e8f295e8b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Configure arguments that are special-handled in
QtProcessConfigureArgs.cmake don't need to be defined in
qt_cmdline.cmake. Remove those.
Change-Id: Ic5959711bfede1eca6d65363c2d005739c7f8aff
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>
This did nothing since the port to CMake, it's undocumented, and we
didn't receive any complaints about its brokenness.
Use CMAKE_CXX_FLAGS to pass arguments like -Wall to the compiler when
building Qt.
Change-Id: Id9976167013607a88959416f789754186a7ed121
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Make them take dash-separated names, not underscore-separated ones.
Amends 9ff1e6d80b.
Change-Id: Ia6af2ef4b422dba74acb4ea835e70045d5f53215
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This commit enables hardened-specific checks and codegen, inspired by
GCC 14's -fhardened command line switch and LLVM/libc++'s hardened
modes.
We enable (depending on compiler capabilities):
* -ftrivial-auto-var-init=pattern;
* -fstack-protector-strong;
* -fstack-clash-protection;
* -fcf-protection=full or /CETCOMPAT;
* -D_FORTIFY_SOURCE=3 or 2 on Glibc, depending on the Glibc version,
provided that some optimization level is enabled (release build or
optimized debug build);
* on libstdc++, -D_GLIBCXX_ASSERTIONS;
* on libc++, -D_LIBCPP_HARDENING_MODE set to
_LIBCPP_HARDENING_MODE_EXTENSIVE in debug and to
_LIBCPP_HARDENING_MODE_FAST in release (_DEBUG is too slow);
* -Wl,-z,relro,-z,now.
This aligns us 100% with -fhardened (we already pass -fPIE and -pie
anyhow). Some Linux distributions already ship GCC/Clang with some of
these options enabled by default.
The check for Intel CET has been amended to always test if the compiler
supports the corresponding flag; and, if so, enable the feature. Before,
it was behind a configure option and the test only checked if the
compiler had CET support automatically active (the test didn't pass
-fcf-protection to the compiler).
The check for -fstack-protector-strong has been made general (rather
than QNX-specific). We don't support QNX < 7 anyhow.
Finally, the qt_config_linker_supports_flag_test test has been
amended to also support MSVC.
All of the hardening options are enabled by default.
[ChangeLog][Build System] Qt builds by default in "hardened mode",
meaning that a series of security-related compiler options are
automatically enabled. In the unlikely case in which these options
constitute an unacceptable performance hit, it is possible to disable
individual hardening options when configuring Qt.
Change-Id: I2c026b0438010ad10d5e7b1136fedf4ae3af8822
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This amends commit 205f8fbff0708ee0425fcf1f300edca4f14da6cc.
We silently supported the values c++14 and c++17 for the -c++std
argument. Support for both versions of the C++ standard was removed in
above mentioned commit.
Change-Id: I8f7dbc33f0a23164f712ac3d2e0a40bb8d12f225
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
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>
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>
This is dysfunctional since Qt 6.0.0.
Change-Id: I22043868c4114c0ea6e18f3be7e056296b663987
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
TestCocoon is not maintained anymore, and the -testcocoon configure
option of Qt didn't do anything useful since Qt 6.0.0.
Remove the option. It's possible to create an instrumented build by
using dedicated CMake toolchain files as described in the documentation
of Squish Coco (TestCocoon's replacement).
Fixes: QTBUG-88316
Change-Id: I8a565cdd288aca9208f48138d2b663802cc0de90
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This option is dysfunctional since Qt 6.0. Modify the CMake variables
CMAKE_SYSROOT_LINK and CMAKE_SYSROOT_COMPILE instead.
Change-Id: Ib97dcc765c4644b5c3975d4b61c0e567451ea977
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This configure option is dysfunctional since Qt 6.0. If you really want
to add the /MP compiler option, add it to CMAKE_CXX_FLAGS.
Change-Id: I00b535067944df52abbadb424ec03e53aa41c819
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This configure option is dysfunctional since Qt 6.0.
Use -cmake-generator instead.
Change-Id: Idb147ec8087018dab3ac0e571eeff7d1f18e34f6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It's unlikely we will ever use pro2cmake at this project stage,
so it doesn't make any sense to keep the 'special case' markers
in the CMake scripts. Remove them and replace with TODO where
needed.
Change-Id: I84290c20679dabbfdec3c5937ce0428fecb3e5a7
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use OpenSSL 3.0 as a provider of all hashing algorithms, except the
BLAKE2b and BLAKE2s. BLAKE2b and BLAKE2s algorithms support a variable
length digest, but OpenSSL's implementation outputs only a digest of a
fixed length (the maximum length supported). This is 512-bits for the
BLAKE2b and 256-bits for the BLAKE2s and for that reason we still use
the original implementation.
[ChangeLog][QtCore][QCryptographicHash] Uses the OpenSSL 3.0
implementation now, where available.
Change-Id: Ia4e4139b92ea9b40a18aa480aa5c06562178f916
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@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>
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>
The mold linker is a new linker for Linux that provides faster link
times compared to BFD ld, ld.gold and lld.
It can be found at https://github.com/rui314/mold
To build Qt with mold, ensure that the binary in your PATH and then
configure Qt with with either
cmake /path/to/qtbase -DINPUT_linker=mold
or
/path/to/qtbase/configure --linker mold
The change was tested with gcc 9, clang 10, clang 12, mold
1.0.0. Only qtbase and qtdeclarative (and dependencies) were tested.
Pick-to: 6.2 6.3
Task-number: QTBUG-99270
Change-Id: I2e64a1f4257c37ff5b64a9326e548b9b46e07c80
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
When qmake and CMake build were both available next to each other, we
answered QMAKE_FOO=bar assignments in the CMake build with an error
message. This code is never triggered these days and can be removed.
Change-Id: Ifd29283b8ddc86b94c4e6cbce9e9252215e9f2fe
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This allows us to present 'qmake' in the tool-related section of the
configure summary.
Change-Id: I897dec23cb0608706ec01d9b91283dbce92b293f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This makes it possible to turn off the build of the Android deployment
tool.
A new src/tools/configure.cmake is added that will be the place for all
tool-related features in qtbase.
Change-Id: Ic9264c93ee96de06c97d21d2f27f73256f48ffda
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
These variable were used in Qt5 to specify the install location of the
DBus library. In Qt6, pkg-config and the usual CMake mechanisms are
used.
Change-Id: Ic3d61d50c1051200c12bac861dc1fbfe0cb8a4a1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The -coverage argument merely added compiler flags for the Qt build. It
was never properly ported to the CMake build, and it doesn't seem
feasible to have configure arguments for every possible compiler option.
The same can be achieved by passing the needed compiler option to CMake,
for example: CMAKE_CXX_FLAGS=-fsanitize-coverage=trace-pc-guard
Pick-to: 6.2
Fixes: QTBUG-86227
Change-Id: Ieef9acaedc0a839f9fb35b4403395eea28643864
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>
Add new configure option -make minimal-static-tests and CMake option
QT_BUILD_MINIMAL_STATIC_TESTS. In conjunction with QT_BUILD_TESTS
it will enable building a minimal subset of tests when targeting
a static desktop Qt build.
In qtbase the minimal subset includes all the auto tests of testlib,
tools, corelib and cmake. In particular this will also do cmake build
tests and qmake build tests (tst_qmake)
Adjust CI instructions to enable building a minimal subset of static
tests when a platform configuration is tagged with the
MinimalStaticTests feature.
Fix and skip a few tests that were failing.
Pick-to: 6.1
Task-number: QTBUG-87580
Task-number: QTBUG-91869
Change-Id: I1fc311b8d5e743ccf05047fb9a7fdb813a645206
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add a conditional build of the qmake.
Task-number: QTBUG-89369
Change-Id: I8d7968ffb20ea31df2f85fff055e0d131ed06a36
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Keep the c++2a feature, but make it an alias for compatibility
purposes.
Pick-to: 6.1
Change-Id: I6f153109be84659806f1b7a57a88a187875166d8
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Add custom targets with '_benchmark' suffixes to make run of
benchmarks using generators possible, e.g.:
$ ninja tst_bench_qudpsocket_benchmark
Extend '-[no]make' option to pass benchmark. Rework
'-[no]make' processing to unify these options processing.
Also looks like it doesn't make sense to enable benchmarks without
having test enabled. So '-DQT_BUILD_BENCHMARKS' enables test as own
dependency automatically.
Task-number: QTBUG-89076
Pick-to: 6.0
Change-Id: Ieee9eadaf6d75a1efec120242d6eb786ace1b071
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Some outdated changes don't get removed when using special case
preservation, so remove them manually.
Change-Id: Iba1481ab9a924c3031bd5ce394d5183a5393f146
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This needs to map to ECM_ENABLE_SANITIZERS.
Fixes: QTBUG-87316
Change-Id: I9e983728af0ba69fd428944e647f0afae8c61772
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If '-make examples -no-compile-examples' was specified, sources of Qt's
examples would be installed, but the examples would not be built.
This switch has always been a source for confusion and is only
interesting for distributors, who can just package the examples
directory tree.
Change-Id: I0291d70e4951d98b553a4abf217db49d05316d3a
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
We extend configurejson2cmake to read the "commandline"
information from configure.json. This data is then translated to CMake function
calls and written it into commandline.cmake files.
We extend QtProcessConfigureArgs.cmake to pick up those commandline.cmake
files to feed our command line handling code, which is a
re-implementation of the command line handling in qt_configure.prf.
The command line handler sets INPUT_xxx variables, similar to
configure/qmake's config.input.xxx variables. The INPUT_xxx values are
translated
- to -DFEATURE_xxx=ON/OFF arguments if the input represents a feature,
- to corresponding CMake variables if such a variable is known,
- or to -DINPUT_xxx=yyy CMake arguments.
Configure arguments that have an entry in
cmake/configure-cmake-mapping.md are actually implemented. Other
arguments are likely to need more work.
Task-number: QTBUG-85373
Change-Id: Ia96baa673fc1fb88e73ba05a1afb473aa074b37d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
