If qtbase was configured with CMAKE_STAGING_PREFIX set to a path without
drive letter on Windows, we must ensure that this exact staging prefix
is propagated to non-qtbase repos.
We already had code that does this for CMAKE_INSTALL_PREFIX. But since
9a74d94ff5 we build our cross-built
packages with CMAKE_STAGING_PREFIX instead of CMAKE_INSTALL_PREFIX.
Move said code into a function and use it for CMAKE_STAGING_PREFIX too.
This fixes Android non-qtbase release libraries not being stripped in
our Windows Android packages.
This amends commit 037fd545c4.
Fixes: QTBUG-104827
Pick-to: 6.2 6.3 6.4
Change-Id: I909f7f39bd0ef7b559619b69f756c042d6c528b0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
when building Qt repositories.
When building for example qtquick3d, the Qt6QmlPlugins.cmake
file should not load the qtquick3d specific plugin config files
because the targets will be created as part of the build and cause
duplicate errors.
We already did it for static builds, but now we also do it for shared
builds.
Amends 7d6f1ee5a7
Amends 98e8180e56
Pick-to: 6.4
Task-number: QTBUG-94066
Change-Id: I66ca71dfa6485eded94c1ecb5eb3b23daf908b39
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
It's deprecated as of Xcode 14, and generates a warning message if a
project explicitly enables bitcode. The App Store no longer accepts
bitcode submissions from Xcode 14.
Pick-to: 6.2 6.3 6.4 5.15
Change-Id: Ib1f9d5114ca4d8b1845ecc7a9de0473ee015db33
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Recents emsdk versions support specifying the method list without
using brackets. Switch to this syntax since that avoids any quoting issues.
Pick-to: 6.4
Change-Id: Ib7bf8ec3f0d2ef67e8222a23e7af9b368ee99a00
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
qt_internal_add_plugin calls qt_set_target_info_properties with the
TARGET_VERSION argument and passes arg_VERSION. However, the function
qt_internal_add_plugin does not have a VERSION argument.
If arg_VERSION is set before calling qt_internal_add_plugin, that value
will be used, and that could be wrong for the plugin.
Remove the TARGET_VERSION argument from the
qt_set_target_info_properties call.
Pick-to: 6.4
Change-Id: I0ae9e0e6636d74fdc20e6ab9ca525c5a9126000c
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
The include paths in QMAKE_INCDIR_FOO entries in qt_lib_XXX.pri files
are filtered to not contain implicit include directories.
We must enclose the regular expression with ^...$ to avoid catching too
many paths like any subdirectory of /usr/include.
Fixes: QTBUG-104736
Change-Id: I2d40e6ec6d3f3421d591fed90b4dd9ebbbeb59f4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously QtModulePlugins.cmake files were only created and
included in static library Qt builds.
Having the targets available in shared library builds would be
useful for custom project deployment purposes. One could query
the location of the plugins or use various generator expressions
referencing their location.
Ensure we always generate and include the QtModulePlugins.cmake files
regardless of the build type.
Allow opting out of including the files by setting
QT_SKIP_AUTO_PLUGIN_INCLUSION to ON, just like we allow for Qml
plugins with QT_SKIP_AUTO_QML_PLUGIN_INCLUSION.
Pick-to: 6.4
Fixes: QTBUG-94066
Change-Id: I69a5dc17762a8e43265578fc33b82b5c4b7a1f5c
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Don't duplicate the logic of plugin package inclusion for each Qt
module. Instead move it into QtPublicPluginHelpers.cmake.
Pick-to: 6.4
Task-number: QTBUG-94066
Change-Id: I5e1f5176a0e754ed56a792c97865752529462617
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Use message(STATUS) for the 'Generating Plugins' message.
This way it will go to stdout instead of stderr, which follows the
convention we have for most of our other messages.
Also list only the modules that actually have plugins, rather than all
known modules.
Pick-to: 6.2 6.3 6.4
Change-Id: I1ea0ed71418ede54790cabd32e03e82fc69f2858
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The previous fix 754512a64d
did not handle qml plugins, which meant that they would still have
hardcoded paths and see warnings like the one below when generating
the prl files
CMake Warning (dev) at
cmake/QtFinishPrlFile.cmake:103 (message):
Could not determine relative path for library
qml/QtQml/WorkerScript/libworkerscriptplugin_debug.a
when generating prl file contents. An absolute path will be
embedded, which will cause issues if the Qt installation is
relocated.
Handle qml plugins as well.
Amends 754512a64d
Amends f4e9981259
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104708
Task-number: QTBUG-104396
Change-Id: Icfb1069d1cb0a39a35004b20e58ee6e386d14f3b
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously if zstd was not found, one would see such a warning message
Could NOT find WrapZSTD: Found unsuitable version "", but required is
at least "1.3" (found ZSTD_LIBRARY-NOTFOUND)
This is because PC_ZSTD_VERSION was a defined variable with an empty
value, which makes FPHSA believe that a version was extracted from
somewhere.
Avoid passing that value directly.
Now the warning message is
Could NOT find WrapZSTD (missing: ZSTD_LIBRARIES ZSTD_INCLUDE_DIRS)
(Required is at least version "1.3")
Pick-to: 6.2 6.3 6.4
Change-Id: I88760d94db0d869d328085996298f4aaa88bc6c2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Rename FindWrapDoubleConversion.cmake into
FindWrapSystemDoubleConversion.cmake.
Merge contents of Finddouble-conversion.cmake into the one above.
This allows users to provide their own Finddouble-conversion.cmake
file (Conan can do it).
Don't mark the system package as required, because we have a bundled
one too.
Add link to upstream.
Make sure to show either Config file or library path when one is
found.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104541
Change-Id: I9ea2330697c6fc280328849ca11522291c4073d8
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This allows picking up 3rd party Find modules. One use case is
Conan-generated Find modules.
Also add TODO in case we ever need to handle finding the upstream
target name rather than the Hunter chosen one.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104542
Change-Id: I243987c657f74e8127076666d9734b2b657bc0ee
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The version option needs to be specified before the COMPONENTS
option, otherwise it is treated as another component.
This causes failures when a Conan provided FindPCRE2.cmake script is
picked up, which actually does validation of component names based
on the component information stored in the conanfile.py recipe.
Move the version value to be before COMPONENTS.
Amends 1007aac63a
Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-104542
Change-Id: I92c70f266a07c4aabdadcecda1ba7e107a033604
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
When recording which package version to look for in
QtFooModuleDependencies.cmake and other files like it,
instead of using PROJECT_VERSION, use the version of the
package that contains the dependency.
For example if we're hypothetically building the qtdeclarative repo
from the 6.4 branch, against an installed 6.2 qtbase, then
the Qt6QmlModuleDependencies.cmake file will have a
find_package(Qt6Core 6.2) call because qtdeclarative's
find_package(Qt6Core) call found a 6.2 Core when it was configured.
This allows switching the versioning scheme of specific Qt modules
that might not want to follow the general Qt versioning scheme.
The first candidate would be QtWebEngine which might want to
follow the Chromium versioning scheme, something like
Qt 6.94.0 where 94 is the Chromium major version.
Implementation notes.
We now record the package version of a target in a property
called _qt_package_version. We do it for qt modules, plugins,
3rd party libraries, tools and the Platform target.
When we try to look up which version to write into the
QtFooModuleDependencies.cmake file (or the equivalent Plugins and
Tools file), we try to find the version
from a few sources: the property mentioned above, then the
Qt6{target}_VERSION variable, and finally PROJECT_VERSION.
In the latter case, we issue a warning because technically that should
never have to happen, and it's a bug or an unforeseen case if it does.
A few more places also need adjustments:
- package versions to look for when configuring standalone
tests and generating standalone tests Config files
- handling of tools packages
- The main Qt6 package lookup in each Dependencies.cmake files
Note that there are some requirements and consequences in case a
module wants to use a different versioning scheme like 6.94.0.
Requirements.
- The root CMakeLists.txt file needs to call find_package with a
version different from the usual PROJECT_VERSION. Ideally it
should look for a few different Qt versions which are known to be
compatible, for example the last stable and LTS versions, or just
the lowest supported Qt version, e.g. 6.2.6 or whenever this change
would land in the 6.2 branch.
- If the repository has multiple modules, some of which need to
follow the Qt versioning scheme and some not,
project(VERSION x.y.z) calls need to be carefully placed in
subdirectory scopes with appropriate version numbers, so that
qt_internal_add_module / _tool / _plugin pick up the correct
version.
Consequences.
- The .so / .dylib names will contain the new version, e.g. .so.6.94
- Linux ELF symbols will contain the new versions
- syncqt private headers will now exist under a
include/QtFoo/6.94.0/QtFoo/private folder
- pri and prl files will also contain the new version numbers
- pkg-config .pc files contain the new version numbers
- It won't be possible to write
find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code.
One would have to write find_package(Qt6WebEngineWidgets 6.94)
otherwise CMake will try to look for Qt6Config 6.94 which won't
exist.
- Similarly, a
find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call
would always find any kind of WebEngine package that is higher than
6.4, which might be 6.94, 6.95, etc.
- In the future, if we fix Qt6Config to pass EXACT to its
subcomponent find_package calls,
a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets)
would fail to find WebEngineWidgets, because its 6.94.0 version
will not be equal to 6.5.0. Currently we don't pass through EXACT,
so it's not an issue.
Augments 5ffc744b79
Task-number: QTBUG-103500
Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
If a find_package(Qt6Foo) call has the QUIET option passed, don't
display the incompatible version warning.
Also if the find_package call has the EXACT option passed, and the
searched for version does not match the package version exactly,
there's no point in showing the warning because find_package
will reject the package anyway, even if we set
PACKAGE_VERSION_COMPATIBLE to TRUE
Pick-to: 6.2 6.3 6.4
Change-Id: I78ef95cf4a045034fc50853465f3ba1db84bba63
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@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>
This will stop working with the next commit, which merges all basic x86
SIMD intrinsics into one configure test. As a result, linking almost
anything graphical on iOS (which is almost everything) causes the linker
to fail with undefined references to SIMD-optimized versions that didn't
get compiled.
Change-Id: Ib42b3adc93bf4d43bd55fffd16c288f4104a6ccc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
I don't know if they've just added the libs and therefore the GSSAPI
content wasn't enabled before, but libgssapi_krb5.so does not have the
symbols we need.
ld: error: undefined symbol: gss_acquire_cred
>>> referenced by qauthenticator.cpp:1803 (/usr/home/tjmaciei/src/qt/qt6/qtbase/src/network/kernel/qauthenticator.cpp:1803)
>>> src/network/CMakeFiles/Network.dir/kernel/qauthenticator.cpp.o:(qGssapiTestGetCredentials(QStringView))
ld: error: undefined symbol: gss_release_name
>>> referenced by qauthenticator.cpp:1808 (/usr/home/tjmaciei/src/qt/qt6/qtbase/src/network/kernel/qauthenticator.cpp:1808)
>>> src/network/CMakeFiles/Network.dir/kernel/qauthenticator.cpp.o:(qGssapiTestGetCredentials(QStringView))
[...]
Pick-to: 6.2 6.3 6.4
Change-Id: I6d3880c7d99d4fc494c8fffd16fabf70bbd272f5
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Make sure to convert absolute paths generated using the
$<TARGET_LINKER_FILE> generator expressions into relative paths.
Because prl files are generated for both modules and plugins, we need
to pass both a list of qt module locations and qt plugin locations
to QtFinishPrl.cmake, and then try to make the absolute path relative
to each passed directory.
A warning assertion is shown if we no relative path could be made,
which will cause an absolute path to be embedded. This should not
happen though.
Amends f4e9981259
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104396
Change-Id: Id68395c0dbb20aad5c510d77835cc931b9396556
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
- USE_WEBGL2 is depreciated, Emscripten now uses MAX_WEBGL_VERSION
- Optimize and remove use of emulated ES2 and ES3, which means
only use WebGL friendly subset.
Users can add USE_ES3=1 and USE_ES2=1 to the final linker arguments
for those respective versions in order to enable using
glDrawArrays and glDrawElements with unbound buffers.
See https://emscripten.org/docs/porting/multimedia_and_graphics/OpenGL-support.html
Pick-to: 6.4
Change-Id: I11ae359966964b3e7aa6e61ccc714c2bfbf61f96
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The variable was misspelt, so we obviously don't need these
exceptions.
Pick-to: 6.4 6.3 6.2
Change-Id: I691c9315bcde3aad72410ce01ae6dc6a013ee6fd
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
We have now had several requests for inlining previously-exported
member functions, but no standard mechanism to effect it.
As QT_REMOVED_SINCE has shown, there is great value in having such a
standard mechanism, so here is one.
With this change, to inline a previously exported (member) function,
simply
- mark the declaration with QT_<MODULE>_INLINE_SINCE
- move the definition into the header file (outside the class),
- wrap it in QT_<MODULE>_INLINE_IMPL_SINCE
- #include the header into the module's removed_api.cpp
Just including the header into removed_api.cpp is enough, so you may
want to add a comment:
#include "header.h" // uses QT_<MODULE>_INLINE_SINCE
The effect is as follows:
- A TU in a _different_ library will see an inline declaration,
followed by the definition, and so it will see a normal inline
function.
- A TU in the same library will, however, see a non-inline
declaration, to avoid the ODR violation that at least GCC/ld are
able to detect.
- When QT_<MODULE>_BUILD_REMOVED_API is in effect, the TU will also
see the definition, which is the same setup as before the change,
except in a different TU, and therefore export the member.
- When, OTOH, QT_<MODULE>_BUILD_REMOVED_API is _not_ in effect, the
TU will see no declaration, assuming (correctly), that the
definition will be supplied by a different TU.
This is, of course, an ODR violation, but not worse than what we do
elsewhere, as the definitions differ only between library and user.
The function is inline only for the users of the library, not the
library itself, which will still see the function as non-inline. If
inlining is critical within the library, too, the existing function
should call a new inline function, and calls in the same library should
be changed to call the new inline function instead.
Use the new mechanism to inline the QLocale ctor we intended to inline
for 6.3, but couldn't, because we hadn't found the magic incantation,
yet. Thiago found it a few weeks later, and this is what this patch is
based on.
Fixes: QTBUG-100452
Pick-to: 6.4
Change-Id: Ia0030cddc64b6b92edfed860170d5204aa74b953
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Changing a C++ source file can trigger rebuilds of a lot of other
source files that might include AUTOGEN'ed headers or sources.
See https://gitlab.kitware.com/cmake/cmake/-/issues/22531 for some
details. Fixed in CMake 3.21.2.
There are still files that are rebuilt even in 3.21.2, but it's less,
and it returns to the status quo of how it was in 3.21.0 or earlier
versions.
Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-104352
Change-Id: Ie1c991d52df48442d4134e4ed22a8137a3c993c8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The test run is wrapped with a special TESTRUNNER script that ignores
failing tests (there are several tests failing when built with ASAN) and
also ignores LSAN errors (memory leaks - but still visible in the
output).
The test run only fails if a test reports ASAN errors or if it
crashes (or times out, which is like a crash caused by qtestlib's
watchdog timer).
Fixes: QTQAINFRA-5025
Change-Id: I861756ab49388ac4a52409d3a780684244e469b1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We're in 2022. A 11-year-old C standard probably suffices, especially
since we require C++17 anyway.
Pick-to: 6.4
Change-Id: Ibcde9b9795ad42ac9978fffd16f3555327097ded
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This will hide the configuration summary and cmake feature summary and
found packages output upon reconfiguration.
Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-104128
Change-Id: I42270b99e45076052ec176df4652661cae10ac0c
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
or when feature changes are detected, even when the log-level is set
to NOTICE (which is the default for non-developer-builds).
We want to show the summary during the first configuration so we don't
force users to look into the config.summary file.
We want not to show the summary upon reconfigurations, to keep regular
reconfigurations as quiet as possibe, so it's easy to notice any new
warnings.
Amends e2a0ddbb69
Amends 384dfceb53
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104127
Change-Id: I506f33b4bae9da8957e04bb69c206bf00e3f7b0e
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
FindWrapSystemHarfbuzz.cmake relied on pkg-config to find system
harfbuzz. This patch makes it find system harfbuzz even if pkg-config
is not available or disabled.
Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-103894
Change-Id: I2a8fc64c738c7604f47de89f387002e40a9fa5e0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We need to check whether pkg_check_modules returns success before
setting up target name etc.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-103894
Change-Id: I12702639683723d976e93be95443099b88885869
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Turning off pkg-config with the configure flag -no-pkg-config did not
work. There are different defaults for FEATURE_pkg_config on different
platforms (e.g. Linux: ON, Windows: OFF). The existing code that
calculated the initial FEATURE_pkg_config value assumed that the default
is OFF and never turned the feature off.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104123
Change-Id: I33b9687c55c60d4ec9224324951a8838741ee976
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
As of Emscripten 3.1.3, the --embind compiler argment has been
depreciated for -lembind
Change-Id: Iac5bc21602f27fda7c1ea6814a1c9525b9a5afab
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Adding specialHTMLTargets to EXPORTED_RUNTIME_METHODS carries the
obligation to actually use it as well; failing to do so makes Emscripten
stop with a reference error on startup.
However, we can't guarantee that Qt will use it in all cases. The
current usage depends on QGuiApplication being used. Application code
could be using QCoreApplication, or no application object at all.
Detect if specialHTMLTargets is present instead, and then enable the code
paths which uses it if that's the case. This means that apps which want
to use e.g. multiple browser windows can opt into support by making sure
EXPORTED_RUNTIME_METHODS contains specialHTMLTargets.
Change-Id: I81105aa01946602fcf593f170e305d7dc9bad3be
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Added a small helper function that also installs the script to
prefix builds. Additionally, leveraging the cmake option
CROSSCOMPILING_EMULATOR for the testrunner fits neatly in the rest
of our cmake code.
Change-Id: I75288e97c81b250ac3997f2e7a22bc7bd82b7b69
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This ensures that the Xcode 'Display name' input under
${target} -> General -> Identity -> Display name is not empty.
Because adding ${PRODUCT_NAME} directly in the Info.plist.in template
will cause CMake to evaluate it as variable expansion, work around the
issue by putting the dollar sign into a separate cache variable that
after evaluation will result in ${PRODUCT_NAME} being in the file
verbatim, so that Xcode evaluate it at build time.
Amends 4d838dae5a
Pick-to: 6.2 6.3
Task-number: QTBUG-95838
Change-Id: I2d1090cc8e84b32442f7daca2d4ce5e3ad413c68
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Currently our iOS CMake toolchain file sets the global
XCODE_EMIT_EFFECTIVE_PLATFORM_NAME property to OFF, to work
around a CMake issue regarding usage of object libraries in
conjunction with Xcode. The error was
The OBJECT library type may not be used for IMPORTED libraries under
Xcode with multiple architectures $(CURRENT_ARCH)
While this got rid of the error, it introduced a regression where
linking an executable against a static library in the same project
failed due to the library not being placed in a directory where Xcode
expects it to be.
clang: error: no such file or directory:
'~/build-untitled4-Qt_6_0_2_for_iOS/Debug/libuntitled4.a'
The actual library is created in Debug-iphoneos/libuntitled4.a
Note the -iphoneos suffix, which is related to the
EFFECTIVE_PLATFORM_NAME.
This could be further worked around by either explicitly setting the
library ARCHIVE_OUTPUT_DIRECTORY property in the project, or flipping
the value of the XCODE_EMIT_EFFECTIVE_PLATFORM_NAME to ON at the
end of the project. Both workarounds are not project-friendly.
In the mean time CMake got a fix for the original error
at https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5771
which got released with CMake 3.20.0.
That was unfortunately not sufficient to remove our initial
workaround, because removing it would trigger a different
error at generation time
CMake Error:
Error evaluating generator expression:
$<TARGET_OBJECTS:Qt6::Quick_resources_1>
The evaluation of the TARGET_OBJECTS generator expression is only
suitable for consumption by CMake (limited under Xcode with multiple
architectures). It is not suitable for writing out elsewhere.
Fortunately, another fix landed in CMake 3.21.0 to address that
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6161
Because static builds (iOS) require CMake 3.21, with both of these
fixes we can now remove our workaround.
Even projects that set ARCHIVE_OUTPUT_DIRECTORY or flip
XCODE_EMIT_EFFECTIVE_PLATFORM_NAME to ON still continue to work
fine.
This also fixes installation of libraries, which also took into
account the effective platform name and thus caused a mismatch between
the expected output dir and the real one.
This reverts 1e1805ed36
Pick-to: 6.2 6.3
Fixes: QTBUG-93268
Fixes: QTBUG-95381
Task-number: QTBUG-87198
Change-Id: Ifcaf0f89e4328ae9859c596882ce32401fa491c3
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
When calling qt-cmake on the command line, we don't usually force
usage of a particular CMake generator and defer to the user's choice
or CMake's default for the host OS.
In the case of iOS, the generator that makes the most sense to use is
Xcode. One could also use Ninja / Unix Makefiles if the project
is only building static libraries, but for shared libraries and
executables the project likely needs the code signing
provided by xcodebuild.
When targeting iOS, use a different qt-cmake file template.
The iOS-specific shell script will set the CMAKE_GENERATOR environment
variable to 'Xcode'.
If no -G or -D CMAKE_GENERATOR is provided on the command line then
the project will use the Xcode generator. Otherwise the generator
given on the command line takes precedence.
The CMAKE_GENERATOR environment variable from the parent process is
completely ignored.
The logic is only done for iOS, to reduce the likeliness
of breaking the qt-cmake script for other platforms.
Note that Qt Creator does not use qt-cmake, but rather calls cmake
directly with additional options like the toolchain file,
architecture, sysroot, etc.
[ChangeLog][iOS][CMake] qt-cmake now defaults to using the Xcode
generator when targeting iOS projects.
Pick-to: 6.2 6.3
Fixes: QTBUG-100834
Change-Id: I39b3dce47cc9ee2f98678631e4bd035c59c65294
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Output names of static libraries might be different from target names.
For example, the library name of Qt6::DeviceDiscoverySupportPrivate is
"Qt6DeviceDiscoverySupport.lib", and the library name of
Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib".
This commit make pdb files names consistent with the library names.
And make sure we have set correct OUTPUT_NAME property before calling
qt_set_common_target_properties()/qt_internal_set_compile_pdb_names().
Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Sometimes it is not desirable to include the libraries in the APK,
e.g. system and vendor apps could prefer having one set of libraries
installed on the device. If unbundled deployment is specified,
native libraries will not be included in the APK.
With unbundled deployment, optional arguments can be passed to
set the path to load the libraries on the device.
[ChangeLog][Android][Deployment Changes] Adds option for Unbundled
deployment, where native libraries are not packaged in the APK.
Task-number: QAA-771
Change-Id: Ica51ef83a24dad58c7586bf610a58abe21fc1100
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
add_custom_command with PRE_LINK doesn't work correctly with
Multi-Config builds. The better solution is to introduce a custom
target that generates the final version script and link the target to
the library target as the dependency.
Change-Id: Ib7420af752a6a46f29f411f9f0dc8557410b4f22
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If QT_GENERATE_WRAPPER_SCRIPTS_FOR_ALL_HOSTS is ON then we generate
Windows scripts on Unix and vice versa. We always used the host
platforms line endings for generating the scripts. This leads to
Windows line endings in Unix scripts and vice versa.
Explicitly specify the line endings style when generating wrapper
scripts.
Fixes: QTBUG-102747
Pick-to: 6.2 6.3
Change-Id: I1603add46f276a5d91bbf0f103a261cdd84c343b
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
qmake adds QMAKE_PRL_LIBS values on the link line after the currently
processed library. Because CMake adds resource object files into
QMAKE_PRL_LIBS, they end up on the link line after the library.
This causes issues on Linux with GNU ld and ld.gold, because the
linker discards symbols from the library which are then later referenced
by the object files.
Work around that by placing the path to the library directly into
QMAKE_PRL_LIBS after the resource object files.
This ensures the linker doesn't discard the symbols required by the
resource object files.
This means that each library encountered in qmake's LIBS variable will
be temporarily referenced twice in qmake's project state: once from
LIBS / QMAKE_PRL_TARGET, and once when the QMAKE_PRL_LIBS values are
added. On the link line it will appear only once though, because qmake
does library deduplication during prl file processing, which only keeps
the last occurrence.
Amends 4ab5432081
Pick-to: 6.2 6.3
Fixes: QTBUG-103002
Change-Id: I97647b64de22b158424850915fee62b5fea5f995
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
JavaScripts's BigInt feature provides support for arbitrary-precision
integers. This makes it possible to represent 64-bit integers; the
standard JS Number type supports 32-bit integers only (or more
accurately 53-bit integers - see Number.MAX_SAFE_INTEGER).
Enable WASM_BIGINT which makes Emscripten map int64_t and uint64_t
to BigInt when interfacing with JavaScript code.
This removes one of the conditions which enables
wasm-emscripten-finalize.
Task-number: QTBUG-103352
Change-Id: Ia70d599daaf34c92695f5a2b61665e0c237e6b95
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: David Skoland <david.skoland@qt.io>
This removes one of the conditions which enables
wasm-emscripten-finalize.
Task-number: QTBUG-103352
Change-Id: Id05db4b081dec360cdad2e611622e5baf09aeb23
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Skoland <david.skoland@qt.io>
find_library does not always work because libatomic.so may be in a path
like /usr/lib/gcc/x86_64-linux-gnu/11/libatomic.so, which CMake does not
consider by default.
Pick-to: 6.3
Change-Id: I73a657c470efa4f84f8629bd531edfcac3b3a352
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Unsetting CMAKE_STRIP and including CMakeFindBinUtils to find it again
is not safe, because CMakeFindBinUtils has logic to search for
additional tool names depending on the currently processed language.
The currently processed language is set in _CMAKE_PROCESSING_LANGUAGE
only when CMake is doing it's language introspection via
CMakeCXXCompiler.cmake.
This resulted in the build system finding a regular host-OS strip,
rather than an android specific llvm-strip when doing an Android
build, which then silently failed to strip the Android libraries
and caused us to ship big binaries.
Improve the strip wrapper creation in a few ways:
- Save the original strip value on first configuration
- Restore it if needed, without using CMakeFindBinUtils
- Don't apply the strip wrapper creation logic to Android,
we currently don't need it there
- Add some informational messages about which CMAKE_STRIP
ends up being used even if log-level is not DEBUG
- Fix a typo
Amends 39f657032b
Pick-to: 6.2 6.3
Fixes: QTBUG-103356
Task-number: QTBUG-101653
Change-Id: I23d98180446d5bb7628e783668f46e4e546ed700
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
...when QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON.
When QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is ON, we want to set
QT_FORCE_BUILD_TOOLS. But this happened too late: after the
initialization of QT_BUILD_TOOLS_BY_DEFAULT. This value depends on
QT_FORCE_BUILD_TOOLS.
This amends commit acfbe3b779.
Change-Id: Ibdba54da943aea1b55618f10d2b8485f4390878a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Replace BOOTSTRAP option with the single value CORE_LIBRARY argument
in qt_internal_add_tool and qt_internal_add_executable functions.
The introduced argument now may accept 'Bootstap' and 'None' values.
Use 'Bootstap' to link Qt::Boostrap library instead Qt::Core or 'None'
to avoid any core library linking. This is useful for tools that need
to use the CMake deployment routines, but not require the Qt::Core
functionality.
Task-number: QTBUG-87480
Change-Id: I64a8b17f16ac5fe43c6b385252dc21def0c88d2c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously, this was only supported when cross-compiling, but that's an
unnecessary limitation. Instead, make it possible to build the "host"
tools (notably qmake) even when they've been found elsewhere due to
QT_FORCE_FIND_TOOLS=ON and a supplied QT_HOST_PATH.
The combination of QT_FORCE_FIND_TOOLS and QT_FORCE_BUILD_TOOLS set to
ON is useful for developers who touch content that ends up in the
bootstrap library.
QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is deprecated in favor of
QT_FORCE_BUILD_TOOLS.
[ChangeLog][CMake] QT_BUILD_TOOLS_WHEN_CROSSCOMPILING has been
deprecated in favor of QT_FORCE_BUILD_TOOLS. The latter can be used in
combination with QT_FORCE_FIND_TOOLS and QT_HOST_PATH to use tools from
a host Qt even for a non-cross build and still build the tools.
Fixes: QTBUG-99683
Change-Id: I0e5f6bec596a4a78bd3bfffd16c8fb486181f9b6
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Otherwise they will just use default compiler
Pick-to: 6.3
Change-Id: Id5813b99fbbb6b0d8b0ee658e06312b637a097c1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If Qt is configured with -platform linux-g++-32 , make sure
to add the -m32 compile options for all built targets.
On 64 bit host OSes that provide both 32 and 64 bit libraries
we need to exclude the 64 bit libraries from being picked up.
The locations of the libraries are distro-specific.
This change by default excludes the Ubuntu x86_64 libraries
paths.
Opt outs are provided, which when used, forces Qt builders to
specify their own ignore paths in a custom CMake toolchain file.
The compile option and default path exclusions are added to the
Qt-generated CMake toolchain file as well, so they are reused
when building other Qt repositories.
Note that there is no foolproof way to tell CMake to ignore all
x86_64 packages / libraries, even if CMake 3.23
CMAKE_IGNORE_PREFIX_PATH is used, because there might not be
a single sysroot to exclude.
Both x86 and x86_64 libraries can co-exist in the same sysroot,
e.g in /usr
One would have to list each package / library directory in
CMAKE_IGNORE_PATH manually.
Additionally, the PKG_CONFIG_LIBDIR environment variable is also set
to Ubuntu specific prefixes, to ensure that pkg_check_modules ->
pkg-config don't pickup x86_64 libraries.
Fixes: QTBUG-101963
Change-Id: Ib17c8d2cd0ba33b2cf748772245bcd558de9120c
Reviewed-by: Jörg Bornemann <joerg.bornemann@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>
message(STATUS) prints output to a buffered stdout, whereas
message(NOTICE) or just message() print to unbuffered stderr.
We use a mix of message() calls when printing the configuration
summary, which caused interleaved output.
Because CMake offers no message(FLUSH), we work around the issue
by calling execute_process(COMMAND -E echo " ") which does
call std::cout << s << std::flush;
We seem to have to do it twice, before and after the
detailed configuration summary is printed.
Pick-to: 6.2 6.3
Change-Id: Ibc075551fc0547073f0696477e54d9b9c1edca97
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
When Qt is configured as relocatable,
QT_CONFIGURE_PREFIX_PATH_STR -> qt_configure_prefix_path_str ->
qt_prfxpath
is not used in relevant code paths.
Specifically qlibraryinfo.cpp getPrefix() uses getRelocatablePrefix()
instead of QT_CONFIGURE_PREFIX_PATH.
Thus, when Qt is configured as relocatable, set qt_prfxpath to an
empty string.
This avoids embedding a CI path like /home/qt/work/install into the
official packages, which makes reproducible builds a closer reality.
Change-Id: I9209b08e651ad0b7fdc4049df333e0978e05f1f5
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
CMake has logic to rewrite build rpaths that contain
CMAKE_STAGING_PREFIX to instead point to CMAKE_INSTALL_PREFIX.
This breaks running executables from the build directory, because
their build rpath will point to a location where the libraries might
not exist yet (we didn't install Qt yet).
Work around this by setting CMAKE_STAGING_PREFIX to a fake path, so
that CMake does not do the rewriting anymore.
CMAKE_STAGING_PREFIX needs to be set at subdirectory scope, not
function scope, which is why
qt_internal_apply_staging_prefix_build_rpath_workaround() is a macro
that is called from within each Qt internal function that creates
a target.
The workaround can be disabled by configuring with
-DQT_NO_STAGING_PREFIX_BUILD_RPATH_WORKAROUND=ON
The downside of this workaround is that it breaks per-subdirectory
install rules like 'ninja src/gui/install'.
Regular global installation like 'ninja install' works fine.
This is similar to what we do for tests in
qt_set_up_fake_standalone_tests_install_prefix()
introduced by 20292250d4
The reason it's not as good for other target types is because in
contrast to tests, we do want to install them.
In case if someone does call `ninja src/gui/install' they will most
likely get a permission error, telling them it's not possible to
install into
/qt_fake_staging_prefix/
check_qt_internal_apply_staging_prefix_build_rpath_workaround
Fixes: QTBUG-102592
Change-Id: I6ce78dde1924a8d830ef5c62808ff674c9639d65
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The change
0ec75f4b99
missed adding specialHTMLTargets for qmake
Also add warning to keep QtWasmHelpers in sync with qmake.conf
Change-Id: Idb363e77f0cecb4f125d3cb4f7507899149a3bac
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
There should be no need for CMake to add rpaths pointing to
directories outside of the build tree to the installed libraries.
All relevant install rpaths are handled by qt_apply_rpaths().
Change-Id: If554b1e3c790c2bb04a34e8b0524aab3febf5afc
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There were a few things that were not ported correctly.
Make sure to disable rpath manipulation if the rpath feature is
disabled.
Fix if(IS_ABSOLUTE) conditions to actually take values.
Don't embed bogus relative rpaths if the platform does not support
it. QNX is such a platform, it does not support $ORIGIN (at least from
my scouring of QNX documentation and manual testing via QEMU).
Handle the extra rpath case where they are relative, but the platform
does not support relative rpaths, by transforming them into absolute
ones.
Amends 67ee92f4d8
Change-Id: I04168633ec51b3cc5d580b738a7dc280fe6e0d2d
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Previously if
-extprefix /tmp/sysroot (CMAKE_STAGING_PREFIX)
-developer-build (FEATURE_developer_build)
were specified, but
-prefix (CMAKE_INSTALL_PREFIX)
was not,
the build system would set the CMAKE_INSTALL_PREFIX to the
qtbase build dir.
Then, if targeting desktop, this would be considered a non-prefix
build (ninja install would refuse to work), whereas in a cross-build
it would be considered an installable build.
In both cases though, the rpath of installed binaries would point to
the qtbase build dir (because CMAKE_INSTALL_PREFIX would be set to the
qtbase build dir).
This is quite confusing behavior, in more than one way.
Change the build system to consider that an explicit -extprefix should
cause Qt to always be installed, even if -developer-build is
specified.
This means the installed rpaths and on-device install prefix
(CMAKE_INSTALL_PREFIX) will now use the default computed install
prefix, e.g. /usr/local/Qt
It also means that to get a non-installable developer + custom staging
and install (on-device) prefix build, users will have to be explicit
and set all the options
-extprefix ~/qt/qtbase_build_dir
-prefix /usr
-developer-build
Pick-to: 6.2 6.3
Change-Id: Ib560452a4b4778860e0fd7666c76f8a6745773ee
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Allow such a combination
- staging prefix (CMAKE_STAGING_PREFIX / -extprefix) set to the
qtbase build dir
- install prefix (CMAKE_INSTALL_PREFIX / -prefix / on-device prefix) set
to some custom location
even for non-cross builds.
An example would be
configure -prefix /usr \
-extprefix ~/qt/qtbase_build_dir
CMake will put the Qt libraries in the qtbase build dir, ninja install
will not be required, but ultimately in order to run applications,
the Qt libraries are expected to be in /usr.
Support for this scenario was originally added for cross-builds in
062318feb2 , but not desktop builds.
Such a build is useful when you want to have install rpaths different
from where Qt is initially installed to (the staging prefix).
This case doesn't really happen often when targeting desktop
platforms, it's mostly used for cross-compilation (e.g yocto).
Being able to have the same setup with a desktop build is nevertheless
useful for faster iteration on build system issues in such a scenario.
Amends 062318feb2
Pick-to: 6.2 6.3
Change-Id: I42be3628a30025f14eebaf0a79401b54e95cde26
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Otherwise we get:
Styles ................................. Basic Fusion Imagine iOS
Material Universal macOS Windows
-- Qt is now configured for building. Just run 'cmake --build .
--parallel'
Pick-to: 6.2 6.3
Change-Id: Ie8d009455e4f45c9eb0557c4a08e9d0a94030c3a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...and properly find and link against `libatomic` using find_library.
This fixes the qtdeclarative build on the RISC-V platform.
Initial-patch-by: Sprite <SpriteOvO@gmail.com>
Pick-to: 6.2
Pick-to: 6.3
Task-number: QTBUG-99234
Change-Id: I2b5e4812886ce45cb02bed3106ce8c519b294cbe
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
We need to add specialHTMLTargets to EXPORTED_RUNTIME_METHODS in order
to use it, as Emscripten does not export it.
Also, EM_ASM is not allowed for SIDE_MODULES, so it's better to use
emscripten::val methods.
Change-Id: I9b352ac98e2a961157f5bb36456bec3e35891270
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This adds significant run-time overhead and should not be on by default.
Pick-to: 6.3
Change-Id: I33d312e31bd714f696d8acf2066eb4b285ff04af
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
When generating .pc files there is a warning when executing
QtFinishPkgConfigFile.cmake:
Ignoring empty string ("") provided on the command line.
This happens because the 'postfix' argument is a part of the script
command line even if it's empty. It also makes no sense to check if
'postfix' is empty using genex, use configuring-time check instead.
Pick-to: 6.2 6.3
Change-Id: If52d9634f4885caefb828976b3c99592a6db3d3c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When PCRE2 is compiled using cmake, a pcre2 cmake file is installed
and Qt fails to configure because components isn't specified for
find_package.
In recent PCRE2 releases components needs to be specified for
find_package.
Fixes: QTBUG-102358
Pick-to: 6.2 6.3
Change-Id: Ib842b2c4b1c0bf38aa5da5475eaa2b3c56c6b822
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
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>
- Currently we manually unpack all platform libraries,
that are required for GUI apps, and pack it into single eglmegapack.a library.
It could be better do not execute such additional step,
but have possibility to add required graphical libs
to cmake interface lib via toolchain file list variable.
Pick-to: 6.2 6.3
Change-Id: Ic4122600f02e6828d528ee4f00075f8c27f42e38
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Originally, QT_INTERNAL_EXAMPLES_INSTALL_PREFIX was added to
control the installation of examples when they are built as
ExternalProjects, and was not considered for the non-EP case because
we hoped to switch entirely to EP-based building.
Due to some unsolved issues regarding using EP builds in CI, add the
ability to control the installation of non-EP examples.
This will be used in the CI to allow removing the hacky
INSTALL_EXAMPLEDIR and INSTALL_EXAMPLESDIR assignments in example
projects.
It is also likely that we will not deprecate the non-EP based
building, because it is useful for IDE integration (EP targets
are not as developer-friendly to work with in an IDE in regards
to rebuilding).
Amends 98c89c8cc1
Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I02264aaa1daa2c80bb9ef3d02b1831b4ca5d2b84
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
to QT_INTERNAL_EXAMPLES_INSTALL_PREFIX so it's clear that the
variable only affects the location of where examples
are installed.
And make sure the paths are passed as CMake paths.
Amends 1031fa1547
Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: Ib92c55488b736d980da2bd88255de78e183de824
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
By default when building ExternalProjects, even if the main ninja
invocation has -v passed, that won't be passed to the nested ninja
calls.
When building examples in the CI, we want to see the full command line
invocations.
Allow passing -v to the nested EP ninja calls by configuring Qt with
-DQT_INTERNAL_VERBOSE_EXAMPLES=ON, which we will use in our CI.
We don't want to add -v by default because if the main ninja does not
have one, the nested calls will still be verbose.
Pick-to: 6.2 6.3
Change-Id: Ifd4b312c6eaa7354e8870f4fb0a77fadf0f33ab7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
So we can see the command line invocations of the built cmake
auto tests.
To achieve that, we create a ninja shell script wrapper, because
ctest --build-and-test does not currently allow specifying custom
build tool options.
Details at
https://gitlab.kitware.com/cmake/cmake/-/issues/22443
Pick-to: 6.2 6.3
Change-Id: I7fb3b7f7f802943a7013c859b2cf39842a34e2e4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Read the ANDROID_<SDK|NDK>_ROOT environment variables in qt toolchain
file and use them to chainload the android toolchain file.
Pick-to: 6.2 6.3
Change-Id: I1940ffbaa557974fc26005f4d051030f2cc5c7e0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add a python script that allows us to run wasm tests in CI, along with
the necessary cmake logic to install the script and execute tests
accordingly.
Change-Id: I93b95c115538c4e27b2b833405acab8162be2a8a
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Fix binary_for_strip project not being found when the following
conditions were met:
- building a repo other than qtbase
- qtbase sources are not available on the machine
(usually happens in CI where only the current repo sources are
available).
The issue was that QT_CMAKE_DIR would always be defined, regardless of
which repo was being built and the system would incorrectly assume
the location of the project files.
The fix is to always pick up the sources from qtbase's source dir if
they are available (this time done with an appropriate check),
otherwise use the installed files.
Note that the behavior of always using the qtbase sources if available
is not exactly the best, but it is a more general issue that affects
other code too.
In the name of consistency, make it so for the binary_for_strip
project as well, but add TODOs in code to address the situation
in a separate change.
Amends 39f657032b
Pick-to: 6.2 6.3
Fixes: QTBUG-102064
Task-number: QTBUG-88090
Task-number: QTBUG-101653
Change-Id: I0649f945e9ff0ab1f597c51bb5ab389fa665c021
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Using INSTALL_LIBDIR is the only reliable way to get the library install directory.
Amends: d1c56073b4
Pick-to: 6.2 6.3
Change-Id: Ib8c4fb8b4d339c63209393d7fdb3d1c3425b03a4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CROSSCOMPILING_EMULATOR is a target property, not a test property.
Fixes: QTBUG-87864
Pick-to: 6.2 6.3
Change-Id: Icb07e9ed71a6bcbfceb7aa2116bf56eaa0a545c6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This option completely ruins the output when running test, as it logs
every single safe heap operation. I don't think this detailed logging
is necessary or reasonable in a normal debug build.
Pick-to: 6.3
Change-Id: I4bb740299d631d21453f9b4a8959634801fb3a1e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
MinGW 11.2.0 comes with a strip.exe that strips the ".gnu_debuglink"
section in binaries, a section that is needed for the separate debug
information feature.
binutils version 2.34 mentions the feature for the first time:
https://sourceware.org/binutils/docs-2.34/binutils/strip.html#strip
To ensure the debuglink section is preserved, generate a shell wrapper
that calls the original strip binary with an extra option to keep the
required section.
To determine if the option is supported, we build a real shared library
on which strip will be called with the --keep-section option.
If the option is not supported, a wrapper is not generated and the
stock strip binary is used.
This logic only applies when targeting Linux and MinGW + a shared
library Qt. For other targets, the stock strip binary is used.
Developers can opt out of this logic by passing
-DQT_NO_STRIP_WRAPPER=TRUE when configuring each Qt repo.
Pick-to: 6.2 6.3
Fixes: QTBUG-101653
Change-Id: Idd213d48d087d3c9600c853362aebaba348cde33
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
So we can see the exact moc invocations when debugging issues in the
CI.
For ExternalProject examples, it is conditional on whether Qt is
configured with QT_INTERNAL_VERBOSE_EXAMPLES set to ON, otherwise
calling the main ninja without -v will end up cluttering the output
with AUTOGEN output.
Pick-to: 6.2 6.3
Change-Id: I6468ab0e461b3be283e2428e3515cae4d5986242
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Since e2a0ddbb69 , if Qt is configured
as a non-developer-build, some of the CMake tests that include QtSetup
would have their CMAKE_MESSAGE_LOG_LEVEL set to the reduced NOTICE
value.
Make sure that tests always have a DEBUG level, so that if they fail
in the CI, we have more info on what goes wrong.
For ExternalProject examples, it is conditional on whether Qt is
configured with QT_INTERNAL_VERBOSE_EXAMPLES set to ON, otherwise
calling the main ninja without -v will end up cluttering the
output a non default log level.
Amends e2a0ddbb69
Pick-to: 6.2 6.3
Change-Id: Icd3b6e0fcc6c73e4b53b6c4a6d8354c96077a050
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
