We should not automatically enable vcpkg as soon as we find it on the
system. With this change, we disable the automatic
detection/integration.
[ChangeLog][configure] Vcpkg detection/integration is now disabled by
default, and it can be enabled by either passing `-vcpkg` to the
configure script, or by passing `-DQT_USE_VCPKG=ON` to cmake.
Change-Id: I4f098db670f11373064c071f1c3204e2e183d3db
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Just a minor change, so that it's clear that we are setting the supplied
toolchain as the VCPKG_CHAINLOAD_TOOLCHAIN_FILE.
Change-Id: I10b35f04e7ad684015062066f67117ce4a964c1c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In order to use multiple toolchain, e.g., when we are cross compiling,
we need to load the detect, and load vcpkg's toolchain after our
toolchain file.
Change-Id: I7f3374363f725a634356788e22ac21835505c4b0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This environment variable is used by vcpkg to avoid having to pass
the --triplet argument on the command line on every vcpkg invocation
and shouldn't influence the triplet used during build. In fact,
the vcpkg.cmake toolchain will automatically attempt to deduce the
target triplet if we don't define this beforehand.
As a replacement, read from the QT_VCPKG_TARGET_TRIPLET environment
variable. It has the QT_ prefix to make it clear this is not a
standard vcpkg environment variable.
[ChangeLog][Build System] Qt no longer uses the VCPKG_DEFAULT_TRIPLET
environment variable to deduce target triplet. By default we let
vcpkg's toolchain file automatically deduce the triplet to use.
The new QT_VCPKG_TARGET_TRIPLET environment variable can be used
instead, or pass -DVCPKG_TARGET_TRIPLET=<triplet> to CMake.
Pick-to: 6.6
Change-Id: Idc6cbd52a68578d1762ca175c4973355409688ac
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
Before this change, we had the following behaviors.
On platforms other than Windows-MSVC:
- when no build type was specified, we defaulted to Release
- when -developer-build was specified, we defaulted to Debug
- regardless of platform, unless the option was explicitly specified,
we never defaulted to -debug-and-release.
On Windows-MSVC, we always defaulted to Debug. Which is inconsistent
with the rules above.
The difference happens because CMake always sets CMAKE_BUILD_TYPE to
Debug during the first project() call when targeting the Windows-MSVC
platform.
We interpreted that as the user setting the build type, and thus we
didn't want to override what the user specified.
After this change, if we detect that it's cmake setting the build
type, we assign a build type that follows the non-Windows-MSVC rules.
This change unifies the behavior across all platforms.
Adjusted the configure help with the new reality.
Augments 33af62db37
[ChangeLog][configure] When no explicit build type is specified,
Windows will now default to building Release like the other
platforms.
Pick-to: 6.5 6.6
Change-Id: Id2bf269c51cf300ec09751ece2ad721869e0f90c
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg 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>
This adds a new platform named wasm-emscripten-64
which sets the build and link argument -MEMORY64
You may see this warning, please ignore at your own discretion:
em++: warning: -sMEMORY64 is still experimental. Many features may not work.
[-Wexperimental]
Fixes: QTBUG-104891
Change-Id: I8d3150d239ba72dbef5c2352e0171d6cfbe51b59
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
macOS Catalina (10.15) has reached its end-of-life, and is no longer
supported with bug fixes or security updates by Apple.
Change-Id: I65d0f572785bc77a563be925cf64823c20b9e015
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Since QtAutoDetect is called before the project, we still don't have
access to our IOS, WATCHOS, TVOS variables, and we must use
CMAKE_SYSTEM_NAME variable instead.
Pick-to: 6.4
Change-Id: I61afe216baec85b3fcd489957f4b6774134f8078
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In addition, I simplified some of the routines as we don't need the
extra check for them.
Task-number: QTBUG-107903
Pick-to: 6.4
Change-Id: Idaf6ab1338a54bc1a9f242fcc8400ae200174beb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Changed `proviude` to `provide`, and removed an extra space in a `xcrun`
command.
Change-Id: Iccbf6f87b9f4c86b686a6b1d0723458a1387a7ea
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>
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>
ANDROID_NATIVE_API_LEVEL is an alias for ANDROID_PLATFORM and the
Android's CMake docs [1] uses directly ANDROID_PLATFORM so let's use
that as well. Also, NDK r23b seems to have removed the part of code from
android.toolchain.cmake that handles ANDROID_NATIVE_API_LEVEL to set
the correct value to ANDROID_PLATFORM.
With this change, CMake will pass the value from the configure argument
-android-ndk-platform as -DANDROID_PLATFORM instead of
-DANDROID_NATIVE_API_LEVEL. Otherwise, if if -DANDROID_NATIVE_API_LEVEL
is passed directly to CMake, it should work as before.
[1] https://developer.android.com/ndk/guides/cmake#build-command
Pick-to: 6.3
Task-number: QTQAINFRA-4837
Change-Id: I5c21af53ac91e11a27c4b033313d22d1115c1abc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We can technically build without Xcode, as long as the command line
tools are installed. We reflect that by an empty QT_MAC_XCODE_VERSION
variable.
Pick-to: 6.2
Change-Id: I40ffa28a628157e0a2c63656065ea7c41a680e01
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Certain platform-related variables, in this case UNIX, must be set in a
platform module, because they get cleared after the toolchain file is
loaded. Such platform modules live in upstream CMake, but there is none
yet for INTEGRITY. This manifests in an undefined UNIX variable and
"System is unknown to CMake" warnings for the project and every
configure test.
Add the CMake module "Platform/Integrity" in the cmake/platforms
directory. Add this directory to CMAKE_MODULE_PATH to let CMake load
Platform/Integrity when the toolchain file set CMAKE_SYSTEM_NAME to
"Integrity".
CMake's module directory takes precedence, when loading platform
modules. This is special for platform modules and different from the
documented behavior of CMAKE_MODULE_PATH and include().
In case the user wants to provide their own platform modules via
CMAKE_MODULE_PATH, they can instruct Qt to not add its path by setting
QT_AVOID_CUSTOM_PLATFORM_MODULES to ON.
Make sure that configure tests with project files also load the custom
platform module.
Pick-to: 6.2
Fixes: QTBUG-96998
Change-Id: I9855d620d24dc66353cec5e847a2675b464ace26
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Rather than fail with obscure can't find Qt packages errors when the
Webassembly CMake toolchain file can not be found, error out with a
clear error on how to ensure it is found.
Pick-to: 6.2
Task-number: QTBUG-96843
Change-Id: I0f34cdcde05efb25c93017f3fd365186335ed52c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Try to to chainload the emscripten CMake toolchain file from the
EMSDK env var if it is set, instead of requiring the user to explicitly
specify a path to the file via QT_CHAINLOAD_TOOLCHAIN_FILE.
The order in which the toolchain file is chainloaded becomes is as
follows:
1) The initial toolchain file path that was specified when configuring
qtbase is set written as the initial value of
__qt_chainload_toolchain_file in qt.toolchain.cmake
2) If EMSDK env var is set, it overrides the value from 1)
3) If QT_CHAINLOAD_TOOLCHAIN_FILE cache var is supplied it overrides
the value from 2)
Whichever value ends up in __qt_chainload_toolchain_file is
checked too see if the file exists.
If it exists it gets included, if it doesn't, a warning is issued.
This checking logic is a bit crude and should be improved and unified
with the Android chainload checking, but the current change already
improves the behavior for users of Qt.
Pick-to: 6.2
Task-number: QTBUG-96843
Change-Id: I5da58a329f659086aaaee765c9399d0369021b22
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Split qt_auto_detect_wasm into multiple helper functions and place
them in a new QtPublicWasmToolchainHelpers.cmake file.
We want to use them to try and detect the CMake toolchain
file location from within the generated qt.toolchain.cmake
file whem configuring a user project.
Pick-to: 6.2
Task-number: QTBUG-96843
Change-Id: Id8c2350e6dbe3c994b435681353bdaee114249a7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This was the case in Qt 5.15 as well.
The CMake toolchain file that Qt's CI is using is already setting
BUILD_SHARED_LIBS to OFF, but it's better to be explicit like we
are with WebAssembly and iOS.
Pick-to: 6.2
Change-Id: Ief17259c15690a97337e9df451663718601c2a52
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Our only way to detect whether the user requests an Android build of Qt
was to peek into the CMake toolchain file if it is specified. If the
toolchain file contains a certain magic string, we decide that we're
building for Android.
This approach is fragile and bound to break should the Android toolchain
file's magic string ever change.
Now, we assume an Android build if any of our ANDROID_* cache variables
is set. In that case, we do not peek into the toolchain file.
Pick-to: 6.2
Fixes: QTBUG-94955
Change-Id: Ie2f0ac0963f90f09805e311111bb6912d4325ada
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This reverts commit 7c62caa355.
Certain toolchain files cannot be read in CMake script mode with CMake
versions >= 3.20.
For example, the vcpkg toolchain file overrides add_executable, and
that fails with CMake 3.20:
CMake Error at D:/dev_tools/vcpkg/scripts/buildsystems/vcpkg.cmake:662 (function):
Built-in flow control command "add_executable" cannot be overridden.
Pick-to: 6.2
Fixes: QTBUG-93627
Change-Id: Ib6e6352dff50b9684dcf81401d138e27e16292c3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Passing Android-related variables to the initial CMake call would have
no effect if no (or an empty) value of CMAKE_TOOLCHAIN_FILE was
specified. To alleviate user confusion, yield an error if an Android
build was apparantly requested, but the toolchain file is missing.
Change-Id: I28ec94eabe436d4b9b410b48c7cad1b48d3e1bec
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before, we relied on the deprecated "ndk-bundle" subdirectory being
present in the SDK root. Now, we choose the NDK with the latest version
in the SDK's ndk subdirectory.
Pick-to: 6.1
Fixes: QTBUG-87579
Change-Id: I37a9e03184f4518b4074d55375af08209591de94
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
When ANDROID_NDK_ROOT is explicitly set by the user, there's no point in
detecting the NDK. The detection had no effect, because the already set
ANDROID_NDK_ROOT variable would not be overwritten by our set call.
Fix the condition of the check: There is no CMAKE_ANDROID_NDK_ROOT
variable.
Pick-to: 6.1
Change-Id: I8f0d4f2a1a67445f67a79c7d2d0932099828b05e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use the same approach we use for iOS, which is to set multiple
CMAKE_OSX_ARCHITECTURES values and let the clang front end
deal with lipo-ing the final libraries.
For now, Qt can be configured to build universal macOS libraries by
passing 2 architectures to CMake, either via:
-DCMAKE_OSX_ARCHITECTURES="x86_64;arm64"
or
-DCMAKE_OSX_ARCHITECTURES="arm64;x86_64"
Currently we recommend specifying the intel x86_64 arch as the first
one, to get an intel slice configuration that is comparable to a
non-universal intel build.
Specifying the arm64 slice first could pessimize optimizations and
reduce the feature set for the intel slice due to the limitation
that we run configure tests only once.
The first specified architecture is the one used to do all the
configure tests.
It 'mostly' defines the common feature set of both architecture
slices, with the excepion of some special handling for sse2 and
neon instructions.
In the future we might want to run at least the Qt architecture config
test for all specified architectures, so that we can extract all the
supported sub-arches and instruction sets in a reliable way.
For now, we use the same sse2 hack as for iOS simulator_and_device
builds, otherwise QtGui fails to link due to missing
qt_memfill32_sse2 and other symbols.
The hack is somewhat augmented to ensure that reconfiguration
still succeeds (same issue happened with iOS). Previously the sse2
feature condition was broken due to force setting the feature
to be ON. Now the condition also checks for a special
QT_FORCE_FEATURE_sse2 variable which we set internally.
Note that we shouldn't build for arm64e, because the binaries
get killed when running on AS with the following message:
kernel: exec_mach_imgact: not running binary built against
preview arm64e ABI.
Aslo, by default, we disable the arm64 slice for qt sql plugins,
mostly because the CI provisioned sql libraries that we depend on only
contain x86_64 slices, and trying to build the sql plugins for both
slices will fail with linker errors.
This behavior can be disabled for all targets marked by
qt_internal_force_macos_intel_arch, by setting the
QT_FORCE_MACOS_ALL_ARCHES CMake option to ON.
To disble it per-target one can set
QT_FORCE_MACOS_ALL_ARCHES_${target} to ON.
Task-number: QTBUG-85447
Change-Id: Iccb5dfcc1a21a8a8292bd3817df0ea46c3445f75
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
A few configure defines get changed:
QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE
QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY
QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE
device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1
To create source maps for debugging. use
device-option QT_WASM_SOURCE_MAP=1
Task-number: QTBUG-78647
Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Includes both minimum deployment targets and minimum sdk
versions.
As per supported Apple platforms versions which was done
in qt/qtdoc at
8807fdedce29cbbd7662fcd745234da30eace3fb
For Qt for iOS 6.0.x we only bump the minimum
deloyment target because applications seem to crash with iOS 12.4+,
and it's better to have a build error than a runtime error.
The minimum required sdk will not be bumped for 6.0.x, so we don't
accidentally break someone's existing build, given that 6.0 is already
released.
Pick-to: 6.1
Task-number: QTCREATORBUG-23574
Change-Id: I3046384164f2d7fdbd0cfd16dcb85e0d60bc56ce
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QtAutoDetect.cmake did read the (possibly detected) toolchain file and
looked for the string "The Android Open Source Project" to deduce that
we want to build for Android. This has been done, because we're
autodetecting the platform before the first project comment, i.e. before
the toolchain file is loaded.
This magic string detection is a bit fragile, and we need a similar
approach for WebAssembly. A more robust approach would be to fetch the
value of CMAKE_SYSTEM_NAME from the toolchain file without actually
loading it.
Now, we run a CMake script that includes the toolchain file and prints
variables were interested in. The calling code reads these variables and
stores them in prefixed variables in the current scope.
Change-Id: Ide9ea3054e1453d17129523e1ec86ecaed55af2a
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The unquoted 'string(FIND ${toolchain_file_content} ...)' call fails for
multiline content of the variable toolchain_file_content, so add
quotes around, fixes:
[...]
CMake Error at cmake/QtAutoDetect.cmake:42 (string):
string sub-command FIND requires 3 or 4 parameters.
Call Stack (most recent call first):
cmake/QtAutoDetect.cmake:311 (qt_auto_detect_android)
CMakeLists.txt:19 (include)
[...]
-- Configuring incomplete, errors occurred!
in case the given toolchain file starts with multiple lines
in the first 80 characters, e.g. in the case of buildroot:
#
# Automatically generated file; DO NOT EDIT.
# CMake toolchain file for Buildroot
#
[...]
Task-number: QTBUG-90980
Pick-to: 6.0 6.1
Change-Id: I8e038e08d83016e8253f2e83b2efb8f06034c6cd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
For now, we only support building Qt with the Ninja generator (and
Ninja Multi-Config).
Issue a warning when a different generator is used.
Allow opting out of the warning by passing
-DQT_SILENCE_CMAKE_GENERATOR_WARNING=ON.
Change-Id: I5faa5b0ca5fd42efc090ad2ccf4f896bd77e50ca
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
On a mac that can build all of Qt with CMake, Ninja, and command line tools,
there should be no warning just because a build tool that
won't get used is not available.
Turn the warning into an informative message instead so that IDE
integrations (such as VSCode's CMake integration) don't flag warnings.
Change-Id: I250c0e5dd0633b36ff2b690a52ba7ce3ceb22218
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The Android toolchain file is now autodetected from the location of the
NDK. The NDK location can be specified by setting the CMake variable
ANDROID_NDK_ROOT. Auto-detection of the Android toolchain file is the
only purpose of this variable.
In recent Android SDK installations the path to the NDK is well-known
and can be auto-detected too. If only ANDROID_SDK_ROOT is given, we try
to detect ANDROID_NDK_ROOT first and from that the Android toolchain
file.
Adjust the build instructions in cmake/README.md, and remove the part
where we suggest to set some environment variables that are only used to
create the cmake call.
Task-number: QTBUG-87068
Change-Id: Ia0df5df7651e98979e9cead1cdae7b17ecbc4afb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Detect an iOS build when either an -sdk option is passed
or when -xplatform macx-ios-clang is passed as a target
mkspec.
Now that CMake 3.17 is released, change the default behavior of the
iOS build to configure with simulator_and_device set to ON, like it
is with qmake.
Update the documentation regarding iOS configuration.
Change-Id: I91aaf706610b8d3c69f1ad4ba9dadee2b1e5db97
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Android minimum API level for Qt 6 is 23, this reflects that to some
instances that still mention 21.
Change-Id: I996f3ed3af14dca114129351d6ea06afcb8f45f5
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This fixes the macOS build when you only have the CommandLineTools installed.
Change-Id: I620bc535b508b604a875f53dec8c57af23efeac1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Sometimes the info we show in the configure summary might differ from
the information that CMake computes.
To more easily debug and fix such cases, print out various CMake info
variables like host and target info, compiler versions, sdk versions,
etc.
Change-Id: I37a11dfabe5369236af78684a09bd3cec3fdd398
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Now that the whole file is not included when doing standalone tests,
the conditions are not needed anymore.
Change-Id: I49ddd2fc4a8327e09529948785f40cda5dedbb11
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Three different people have encountered the issue that calling
calling qt-cmake on a project prints 1000 inclusion lines of the same
qt toolchain file, and then CMake bails out saying can't find the
CMAKE_MAKE_PROGRAM Ninja.
This happened because people accidentally called qt-cmake to configure
qtbase (instead of just cmake), which created a toolchain file that
chainloads itself recursively.
Error out when configuring qtbase, and when using the generated
toolchain file in the case when it would try to include itself.
The solution is to remove the qtbase CMakeCache.txt file, and
configure qtbase again, so it generates a proper qt.toolchain.cmake
file.
If somebody feels enthusiastic, they can move the check into the
qt-cmake and qt-cmake-private shell scripts, and error out before the
qtbase/CMakeCache.txt is polluted with the wrong toolchain file.
That is left for people that feel more comfortable with bash and batch
scripting.
Change-Id: If518c94791fe7c30731e6e462e347f26a5213c64
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Thus we will build both Release and Debug configurations in Coin
when cmake --build . is executed, mimicking qmake's make which
builds both configurations in debug_and_release.
Task-number: QTBUG-80900
Change-Id: If48aca249eb84e690d3f9d51a733b3a25df1f7ca
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Instead of using CMAKE_INSTALL_RPATH to embed an absolute path
to prefix/libdir into all targets, use the more sophisticated aproach
that qmake does.
For certain targets (modules, plugins, tools) use relative rpaths.
Otherwise embed absolute paths (examples, regular binaries).
Installed tests currently have no rpaths.
On certain platforms rpaths are not used (Windows, Android,
iOS / uikit).
Frameworks, app bundles and shallow bundles should also be handled
correctly.
Additional rpaths can be provided via QT_EXTRA_RPATHS variable
(similar to the -R option that configure takes).
Automatic embedding can be disabled either via QT_FEATURE_rpath=OFF
or QT_DISABLE_RPATH=ON.
Note that installed examples are not relocatable at the moment (due
to always having an absolute path rpath), so this is a missing feature
compared to qmake. This is due to missing information on where
examples will be installed, so a relative rpath can not be computed.
By default a Qt installation is relocatable, so there is no need to
pass -DQT_EXTRA_RPATHS=. like Coin used to do with qmake e.g. -R .
Relative rpaths will have the appropriate 'relative base' prefixed
to them (e.g $ORIGIN on linux and @loader_path on darwin platforms).
There is currently no support for other platforms that might have a
different 'relative base' than the ones mentioned above.
Any extra rpaths are saved to BuildInternalsExtra which are re-used
when building other repositories.
configurejson2cmake modified to include correct conditions for the
rpath feature.
It's very likely that we will need a new qt_add_internal_app()
function for gui apps that are to be installed to prefix/bin.
For example for Assistant from qttools. Currently such apps
use qt_add_executable().
The distinction is necessary to make sure that relative rpaths are
embedded into apps, but not executables (which tests are part of).
Amends e835a6853b
Task-number: QTBUG-83497
Change-Id: I3510f63c0a59489741116cc8ec3ef6a0a7704f25
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
