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>
