It's unlikely that C++ code needs to query that feature. It also
causes full rebuilds of Qt if the feature's value is toggled.
Remove the no-prefix define from qconfig_p.h.
Pick-to: 6.5 6.6
Task-number: QTBUG-116689
Change-Id: I7d968b1c3d6bff3653e1233cea09a36579776347
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The displayed failure messages were missing the label, making the
output confusing.
Pick-to: 6.5 6.6
Change-Id: I4e20687f85b651dcac66ebd6e0881809dc0be709
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
As mentioned, separate debug info will always be generated when building
with `-release -force-debug-info`.
Pick-to: 6.5 6.6
Fixes: QTBUG-108015
Change-Id: I49e79177ca833007b932b58a76261c07acd52ca6
Reviewed-by: Alexey Edelev <alexey.edelev@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>
I think this needs to be more prominent, as I noticed during the testing
that it could cause issues if it gets lost in between the config
messages, as we knew of course.
Pick-to: 6.5 6.6
Task-number: QTBUG-113463
Change-Id: I2ece498a8d3604362a49cc10499b92b0d2764fb9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Without enabling FEATURE_msvc_obj_debug_info ccache does not work
for me with msvc.
So, enable it along with -ccache to make things easier.
Change-Id: Ic6cf6ebddb4a5dce6a04987fba1a1f437b286e90
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
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>
Qt requires them and will fail to build if it isn't met, so we don't
need to check for its support. These were public CMake and qmake
features, so to keep compatibility with existing they're hardcoded now
(only done for the C++ editions and for qmake only, as that's what Qt 5
did).
Change-Id: I7f354474adce419ca6c2fffd174814724f45f90b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Maintain one central place - .cmake.conf - for information
about Qt's copyright.
Pick-to: 6.2 6.5
Change-Id: Ibcbce4313eba9660d459061b0ad00307e267b8f7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add it globally so that each module using tracepoints don't have to
add it themselves to each modules configure.cmake.
Pick-to: 6.5
Change-Id: Id58cfaff5cd715b2667da2470001d646117f9f28
Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
As of f68e2c92cc, and its follow up
changes, we can now link individual plugins statically, even if the
Qt build is generally a shared build.
This allows us to build Qt for iOS as shared libraries, while still
keeping the platform plugin as a static library, since this is
harder to port over to a shared library.
This gives the benefit of faster turnaround during development, as
well as binary compatibility promises for the main Qt libraries,
without having to go fully shared for all of Qt.
Static builds are still the default, due to the downsides of larger
application bundles and slower load times for shared builds.
For now the user has to manually tick the "Embed & Sign" check
box in Xcode for each Qt library, which is only available with
Xcode projects generated by the qmake Xcode generator.
Task-number: QTBUG-85974
Change-Id: Id2b7bd2823c8e7c79068dda95295b574ada8d7f2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Make options for enabling "simd128" and "exceptions" public:
-feature-wasm-simd128
-feature-wasm-exceptions
Make sure both appear in the config summary and feature
list. Move the exceptions code so that they are next to
each other in the cmake file.
Pick-to: 6.5
Change-Id: I3975b56703f40f7ffff270754535bc2eb5bfe488
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
clang-cl's intrinsics support is broken, it doesn't declare the AVX2
intrinsics if they are disabled and this doesn't match GCC or MSVC
behavior: https://github.com/llvm/llvm-project/issues/53520
This fix allows to disable x86 intrinsiscs during configuration of
clang-cl build.
clang-cl build is still not guaranteed to work with enabled x86 intrinsics.
Change-Id: Icd295f6b4d868adf10bcd425d5280c56b43cb9f7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Otherwise certain features may act as enabled even though they're
not supposed to be
Pick-to: 6.4
Fixes: QTBUG-108611
Change-Id: Id4b4bcb7a8f437e2d12b2a2f9b3ce2d4463b8be8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Add support for enabling -fwasm-exceptions at compile and
link time, which enables use of C++ exceptions.
Wasm-exceptions is an in-progress roadmap item (see
https://webassembly.org/roadmap/), but is supported
by the major browsers
Change-Id: I6e2847206a46ed8038320c99725bc09a0344d1b4
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Locally I cannot build Qt with the default ld linker.
Only enabled bfd and lld because mold and gold is not available
for Windows.
Pick-to: 6.4 6.2
Change-Id: Ib57562b07219acc47f53fe5b0944f54d9c2a6ba6
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Add Qt configure feature for enabling WebAssembly SIMD usage:
./configure ... -feature-wasm-simd128
Enabling this feature makes Qt add the -msimd128 flag to
the compile options, which enables SIMD instruction usage
for the compiler.
(This should not be confused with the previously added SSE
SIMD support, which uses Emscripten's support for translating
SSE SIMD to WASM SIMD)
Change-Id: I84a36ccef8abf9199c304d68ce371c6b1747b832
Reviewed-by: David Skoland <david.skoland@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
OpenSSL by default doesn't provide static libraries and we would fail to
build it in such case.
Fixes: QTBUG-106978
Change-Id: I456fe9bec2bbef5003de8f6cb7d9d8bb226821f9
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The full name should obviously indicates what the feature is, no need to specify LTO explicitly. And it also make the line a little longer than it should be. But we should keep LTCG (Link Time Code Generation) in case the user don't know LTCG also refers to this feature.
Change-Id: I95a2e5335d0b76c40c67f0484d77a4d50f5fd85f
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>
Keep the line short. While at it, also mention Intel, because
that's where the technology is available at (and searching for
Intel CET will lead you to the right places).
Change-Id: Iefe0d735a814880d49fbe82cfd3a790af656377e
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This implements the build system bits required to build Qt
as as separate wasm modules a.k.a Emscripten side modules.
Enable by configuring with the "-shared" flag.
This is the first step towards shared library support and gets
us as far as being able to load QtCore and instantiate a
QCoreApplication.
Task-number: QTBUG-63925
Change-Id: Ib8f07f80fb5b13c8dbba65c7db735dc557b70d0e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@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>
The feature is not ready for prime-time. Too many linker bugs have been
found, Clang hasn't finished implementing it, and the status of gold and
lld are simply unknown.
Task-number: QTBUG-105002
Pick-to: 6.4
Change-Id: I3859764fed084846bcb0fffd1702fead133a9a96
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And take the opportunity to remove the "m" in the qmake feature name and
.prf file.
Pick-to: 6.4
Change-Id: I36b24183fbd041179f2ffffd170224ab75cdd968
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use the full name of LTCG to make it clearer to the user.
As a drive-by, also remove the "Intel" word from the
CET feature's title, according to MSVC & GCC's manual,
they don't contain "Intel" in the feature title either.
Change-Id: I099ba6c5e7470b5699c1ab6b3c4ef2a4bf084580
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The zstd feature might have different values between the host
and target, in which case qmake must tell rcc not to use zstd
when the feature is disabled.
Amends 14546d1816
Fixes: QTBUG-103794
Pick-to: 6.4 6.3 6.2
Change-Id: Ia0378742a50e2a85f59985dea2506d3dda5f28e8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Use a more detailed description instead.
Also adds the missing part of the GCC parameter.
Amends commit qtbase/42287255d38bf493b5731396b99bc9cd7b1baba4
References:
https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Instrumentation-Options.html#Instrumentation-Options
Change-Id: I94a22ac7dfa80644e92fe01021f7868dfa02dd69
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Merge all the existing checks into a single one, which is a simple pass
or fail, since all our supported compilers support all the intrinsics up
to Cannon Lake. The two I've recently added (AVX512VBMI2 and VAES)
aren't yet supported everywhere, so they stay.
For some reason, all intrinsics seem to be disabled on Android. It looks
like some support was missing during the CMake port and this was never
again looked at. I'm leaving it be.
As for WASM, discussion with maintainers is that the WASM emulation of
x86 intrinsics is too hit-and-miss. No one is testing the performance,
particularly the person writing such code (me). They also have some
non-obvious selection of what is supported natively and what is
merely emulated. Using the actual WASM intrinsics is preferred, but
someone else's job.
Change-Id: Ib42b3adc93bf4d43bd55fffd16c10d66208e8384
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The GNU binutils ld linker needed a patch after the tagging of 2.38 to
make the new feature work. Before this patch, the linker will fail to
link when protected visibility symbols are used in the library, so don't
enable the feature unless the linker is recent enough.
GNU binutils gold from that version passes this test.
LLVM lld is unknown (I didn't test), but LLVM was consulted in
developing the feature.
Fixes: QTBUG-103493
Change-Id: Ibcde9b9795ad42ac9978fffd16f1c80ca20953ff
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Do build zlib as static 3rdparty library. This makes it easier to
disable warnings.
Pick-to: 6.3
Change-Id: I1db331b671b64e68d81c56b0df337983c3bbe7fa
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Instead of complicating the condition even more, just use the value of
QT_WILL_INSTALL which is determined in QtSetup before configure.cmake
is loaded.
The AUTODETECT part is needed to ensure that
-developer-build
implies -no-prefix.
The CONDITION part is needed so that
-extprefix /tmp/sysroot -no-prefix
correctly errors out saying that this can't be a non-prefix build,
unless
-extprefix ${qtbase_build_dir} -no-prefix
is passed.
Pick-to: 6.2 6.3
Change-Id: Ie4f5a91281bf2fbe1bd0744de05d57f43fe992e7
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This fixes the "Could not find feature c++2b." error when building a Qt
module with qmake.
The feature is OFF by default for now.
This amends commit b5ed3cb7ba.
Pick-to: 6.2 6.3
Change-Id: Ibabe3ce29275699e66ab1f32d19d583d6bcede9e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The -mno-direct-extern-access tells the compiler and linker that
references to symbols outside this ELF module mustn't be direct and must
instead always go through the GOT or PLT (the PLT can additionally be
disabled with -fno-plt). The ELF protected visibility tells the compiler
and linker that this symbol is present in the dynamic symbol table as an
export, but it cannot be interposed by another ELF module.
This option is required for user code to link properly to Qt, otherwise
they will get linker errors (assuming GNU binutils >= 2.39) or runtime
failures (glibc >= 2.35). Both versions of glibc and binutils are older
than GCC 12, so it's a safe assumption they are in use and downgrading
the toolchain or libc is not supported. Adding this option to the
compilation is assured for CMake and qmake-based projects.
For example, all accessess to QCoreApplication::self in QtCore, after
this change and with GCC 12 are relocation-free and direct:
000000000013ebf0 <QCoreApplicationPrivate::checkInstance(char const*)>:
13ebf0: cmpq $0x0,0x4f73d0(%rip) # 635fc8 <QCoreApplication::self>
13ebf8: setne %al
13ebfb: je a90fe <QCoreApplicationPrivate::checkInstance(char const*) [clone .cold]>
13ec01: ret
Meanwhile, accesses to the same variable in other modules are indirect
via the GOT:
66650: mov 0x876e1(%rip),%rax # edd38 <QCoreApplication::self@Qt_6>
66657: cmpq $0x0,(%rax)
This replaces the -Bsymbolic and -Bsymbolic-functions (broken)
functionality that Qt has been using or attempting to use since ~2006.
See https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_606975128
Change-Id: Iad4b0a3e5c06570b9f5f571b26ed564aa0811e47
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We have VAES code in qhash.cpp that isn't getting compiled right now.
Change-Id: Ibf4acec0f166495998f7fffd16d6961261dec361
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
And the target ZSTD::ZSTD to WrapZSTD::WrapZSTD.
This should allow building Qt with the
-DCMAKE_FIND_PACKAGE_PREFER_CONFIG=ON set.
Pick-to: 6.2 6.3
Fixes: QTBUG-100537
Change-Id: I748601e4ad6f518323bf1034d6fc1de582c815e1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
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>
All[*] compilers support it, always. The last to not support it was GCC
4.8, which we don't support in Qt 6.
[*] Anecdotally, clang-cl doesn't but clang-cl isn't supported and that
would be an upstream problem: clang-cl developers must find a solution
that either matches Clang or cl.exe.
Change-Id: I54f205f6b7314351b078fffd16d0a5ed5b7afae5
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
