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>
Only show the more verbose configure output when configuring
with -developer-build (which matches --log-level=STATUS)
Otherwise in a non-developer build, restrict the output
to NOTICE+ message (includes WARNINGs and ERRORs).
Developers can still pass a custom log level when configuring.
For example -DCMAKE_MESSAGE_LOG_LEVEL=STATUS or
--log-level=STATUS.
The former method will be cached, while the latter is only applied
to the current configure invocation.
Also show the build instructions hint message only when configuring
for the first time.
[ChangeLog][CMake][configure] The configure output verbosity of
non developer-builds of Qt is now reduced by default. Pass
"-- --log-level=STATUS" to configure to make it verbose again.
Pick-to: 6.2 6.3
Change-Id: I7583a9c92142e0b1d7c5411b06403f40d8ebaf20
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Introduce a new -no-prefix option that can be used to build Qt without
having to install it.
Currently, -no-prefix is already implied by -developer-build, but
-developer-build also implies -warnings-are-errors and
-feature-private-tests, which not everyone might want to use.
Some Qt builders likely use -developer-build for the no-prefix
behavior, hence we introduce a standalone -no-prefix option to offer
a nicer user experience without -Werror and friends.
Previously it was possible to achieve the same by specifying
-prefix $PWD, but that relies on $PWD expanding property in the used
shell.
The new -no-prefix doesn't depend on the type of the shell and
is shorter to type.
Internally this gets passed by configure as -DINPUT_no_prefix=yes to
CMake, and transformed into a -DQT_FEATURE_no_prefix=ON feature.
The feature also gets automatically auto-detected to ON if
developer-build is set, -prefix is either unset or $PWD.
CMake code should still query QT_WILL_INSTALL to decide whether
files need to be installed or not.
As a drive-by, we now also export QT_FEATURE_developer_build to
be available for querying during configuration of other repos
(previously it was only possible to query FEATURE_developer_build).
Pick-to: 6.2 6.3
Change-Id: Iaa6c8d8ae2b736282e9949d2a5d7f412e290a253
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
For cross-compiled conan packages we need conan to export QT_HOST_PATH
as an environment variable. The Qt build now picks up this environment
variable if no QT_HOST_PATH cache variable was specified.
Pick-to: 6.2 6.3
Change-Id: I0c3e15e82842061d5db81949ffcc1c240f6ed6a4
Reviewed-by: Iikka Eklund <iikka.eklund@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
In a single-config build on Linux, we usually don't want a debug
postfix in library names (as opposed to Windows/macOS).
But when doing a multi-config build on Linux, assigning no postfixes
causes CMake to generate rules for a single config only, the first one
specified in CMAKE_CONFIGURATION_TYPES.
This leads to being unable to build all configurations from the same
build.ninja file as well as other obscure issues like race-conditions
when generating prl files.
To address this, when doing a multi-config build, always assign a
postfix for each config except the first release-like one, while
preserving the existing rules we had for debug postfix names.
Pick-to: 6.2 6.3
Fixes: QTBUG-100493
Change-Id: Ie9c88e074abdcf2961d7b3dee19a5694292717b8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
There are issues when building examples as external projects in the CI
in child repos like qtsvg.
QEMU configurations fail to find some CMake Config files, Windows
configs fail to find libraries.
Until these issues are fixed, build examples in-tree (without using
external projects) like we did before.
Temporarily disables 98c89c8cc1
Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: Ia4b39812b27cfde5f5a103fd39cc1cb032842643
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Change prefix builds to use ExternalProjects to build examples
by default. This will affect our CI which only does prefix builds.
To make it work, we have to do a few adjustments:
- look for Config files in the build-tree (before Qt is installed)
- build only one examples with only a single config,
even if Qt is a multi-config build
- install examples as part of main make install step, rather than
as part of the make step (which is the default for EPs)
- adjust CXX flags when building with MSVC to ensure we can still
use sccache and separate debug info
- derive the correct install prefix for each example and pass it
to the ExternalProject
As a drive-by, add TODOs to address tidiness of the code and corner
cases that likely don't work (Conan).
Amends d97fd7af2b
Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This will show the CMAKE_BUILD_TYPE that was computed for a configured
repo or standalone tests, after the logic in
QtBuildInternalsExtra.cmake is executed.
Pick-to: 6.2 6.3
Change-Id: Ib8ffa2c7806a4c16385a2fcd4500f8a0f6a9aa88
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In non-prefix builds, we want to prevent users from accidentally running
"cmake --install". We did that by replacing cmake_install.cmake with an
empty file.
The responsible target remove_cmake_install is visible in IDEs, appears
in the build output, and the approach is hacky.
It's cleaner and easier to add bail out code at the top of
cmake_install.cmake. This is now done when calling qt_build_repo_begin.
As a bonus, print an informative message on installation.
Change-Id: I022b36289358ba09cac8b79781f44cd7b93113f7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We default to configuring examples as separate ExternalProjects when
using a developer / non-prefix Qt build.
This ensures we test that the examples configure successfully without
the pollution of the main Qt build (e.g. already found packages).
One down-side of this is that a developer's IDE doesn't see these
example targets, unless each project is loaded into the IDE
separately. This is cumbersome to do when refactoring or renaming
code across multiple example projects.
Allow configuring the example projects as part of the main Qt build
by setting QT_BUILD_EXAMPLES_AS_EXTERNAL to FALSE when configuring Qt.
Save the value of the variable in QtBuildInternalsExtra.cmake.in
so it's propagated to leaf repositories as well.
Amends dab8f64b6d
Amends d97fd7af2b
Task-number: QTBUG-90820
Task-number: QTBUG-94608
Task-number: QTBUG-96232
Task-number: QTCREATORBUG-26168
Pick-to: 6.2
Change-Id: Ie1f724f74365b3a788b04c3fffe9eb2d0611dd50
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Before, we would just issue a warning which is likely to get overlooked
in CMake's output. Also, the configure summary would report "Using
ccache ... yes" but CMAKE_<LANG>_COMPILER_LAUNCHER stays unset, which is
inconsistent.
Make QT_USE_CCACHE=ON and missing ccache a hard error.
Task-number: QTBUG-88308
Change-Id: Iddc7f3a91428fd96ad0defbb1ca72bd46a90aa98
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Change the default installation prefix to C:/Qt/Qt-${version} on Windows
and /usr/local/Qt-${version} elsewhere.
This is what's expected by users coming from Qt5, and setting the
installation prefix to "/usr/local" manually is easier than setting the
versioned variant "/usr/local/Qt-6.2.0".
[ChangeLog][Build System] The installation prefix now defaults to
/usr/local/Qt-${version} and C:/Qt/Qt-${version} like it did in Qt 5.
Fixes: QTBUG-91632
Pick-to: 6.2
Change-Id: I8ce57b1b18084c705b194c776e038cc807a6ed5e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Ensure that Qt user projects build with sanitizer flags if Qt was
configured with any of the sanitizers enabled.
To compile Qt with sanitizer support enable any of Qt sanitizer
features.
Passing -DECM_ENABLE_SANITIZERS=address to CMake is NOT supported
anymore.
When configuring Qt using CMake directly, pass
-DFEATURE_sanitizer_address=ON
-DFEATURE_sanitizer_undefined=ON
instead of
-DECM_ENABLE_SANITIZERS=address;undefined
When configuring Qt with the configure script pass
-sanitize address -sanitize undefined
as usual.
QtConfig.cmake now records the sanitizer options that should be
enabled for all consuming projects based on the enabled Qt features.
This applies to internal Qt builds as well as well as tests an
examples.
The recorded sanitizer options are assigned to the ECM_ENABLE_SANITIZERS
variable in the directory scope where find_package(Qt6) is called.
The ECMEnableSanitizers module is included to add the necessary flags to
all targets in that directory scope or its children.
This behavior can be opted out by setting the
QT_NO_ADD_SANITIZER_OPTIONS variable in projects that use Qt and might
be handling sanitizer options differently.
Amends 7e03bc39b8
Pick-to: 6.2
Fixes: QTBUG-87989
Task-number: QTBUG-92083
Change-Id: I2e3371147277bdf8f55a39abaa34478dea4853a6
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Add new configure option -make minimal-static-tests and CMake option
QT_BUILD_MINIMAL_STATIC_TESTS. In conjunction with QT_BUILD_TESTS
it will enable building a minimal subset of tests when targeting
a static desktop Qt build.
In qtbase the minimal subset includes all the auto tests of testlib,
tools, corelib and cmake. In particular this will also do cmake build
tests and qmake build tests (tst_qmake)
Adjust CI instructions to enable building a minimal subset of static
tests when a platform configuration is tagged with the
MinimalStaticTests feature.
Fix and skip a few tests that were failing.
Pick-to: 6.1
Task-number: QTBUG-87580
Task-number: QTBUG-91869
Change-Id: I1fc311b8d5e743ccf05047fb9a7fdb813a645206
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Developer builds with RelWithDebInfo should also make benchmarks, it
is how we get good traces.
Change-Id: I009d40580d5d784f78bd18ebf21887ce3c1fa97d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In QtSetup.cmake the PROJECT_VERSION_MAJOR variable was used to
identify prefix of 'Qt<version>HostInfoConfig.cmake'.
Qt<version>HostInfo is not found, if project version differs
from qtbase version.
Move the 'INSTALL_CMAKE_NAMESPACE' and 'QT_CMAKE_EXPORT_NAMESPACE'
variables to 'QtBuildInternalsConfig.cmake'. In this case
variables will be exposed for a wider list of internal routines.
Use the 'INSTALL_CMAKE_NAMESPACE' variable as prefix to find
Qt<version>HostInfo module.
Fixes: QTBUG-90345
Change-Id: Ic595d1c5beb74f34e69b58e18590a3afc2f346f7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
'QT_HOST_PATH' indicates that we use crosscompilation toolchain
to build project. In this case 'Qt6Config.cmake' loads
'Qt6HostInfoConfig.cmake' from host QT_HOST_PATH, that defines
correct paths to host tools.
Replace hardcoded paths for host tools by paths recorded
in Qt6HostInfoConfig.cmake.
Correct conditions for QT_HOST_PATH, evaluate it explicitly as
string, but not as boolean expression.
Fixes: QTBUG-86557
Pick-to: 6.0
Change-Id: Ib52bbd32478051d019a932dcb1f735e2d4aacfbf
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Unset all QT_FEATURE_foo values for every build.
If any of FEATURE_foo is different of QT_FEATURE_foo, mark whole Qt
build as dirty. Reset FEATURE_foo for dirty builds to the calculated
value if it doesn't meet its condition.
Set Qt module as NOT FOUND if its target was not created during
configuration.
Main issue with this approach are generated files, that became trash
once the related features are disabled. This especially affects features
that enable/disable Qt modules. FooConfig.cmake files are created and
generate lots of warnings if feature was disabled. We may introduce a
module cleanup procedure at some point.
Fixes: QTBUG-85962
Pick-to: 6.0
Change-Id: Id71c1edb4027b24c6793063e40cc9d612c24ebce
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Disabled by default as they are currently not being built and many are
not working properly, this will allow us to start using them again.
Change-Id: I823368d04e9fde2beccabedc3ca15efd1f355bfb
Pick-to: 6.0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add custom targets with '_benchmark' suffixes to make run of
benchmarks using generators possible, e.g.:
$ ninja tst_bench_qudpsocket_benchmark
Extend '-[no]make' option to pass benchmark. Rework
'-[no]make' processing to unify these options processing.
Also looks like it doesn't make sense to enable benchmarks without
having test enabled. So '-DQT_BUILD_BENCHMARKS' enables test as own
dependency automatically.
Task-number: QTBUG-89076
Pick-to: 6.0
Change-Id: Ieee9eadaf6d75a1efec120242d6eb786ace1b071
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For consistency, apply the following renamings:
QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT
QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT
QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT
BUILD_EXAMPLES -> QT_BUILD_EXAMPLES
BUILD_TESTING -> QT_BUILD_TESTS
This should help to better convey the difference between "BUILD" and
"NO_MAKE".
To configure tests, but not to build them by default, pass the
following to CMake:
-DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF
Analoguous for examples:
-DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF
Tools can be excluded from the default build with:
-DBUILD_TOOLS_BY_DEFAULT=OFF
The variable BUILD_TESTING is still available and initialized with the
value of QT_BUILD_TESTS.
Pick-to: 6.0 6.0.0
Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If the user turns on debug_and_release with the configure script,
FEATURE_debug_and_release will not be set, and the debug postfix won't
be set correctly.
Directly use FEATURE_debug_and_release's condition instead.
Change-Id: Ica4af3caa25f2e6712eca4659818aac2c8b95256
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Configure now translates -developer-build to INPUT_developer_build
without setting FEATURE_developer_build.
The install prefix determination code in QtSetup.cmake happens much
earlier than the feature evaluation. As the developer_build feature is
merely a switch that's supposed to be flipped by the user, we can just
translate the INPUT_developer_build value to FEATURE_developer_build in
QtSetup.cmake.
Fixes: QTBUG-88318
Change-Id: I57918232359e2e367e41b779d3f4737731dd76e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This option maps to FEATURE_reduce_exports. The feature is on by
default, except for MSVC. The reduce_exports configure test is not used
in the CMake build.
The <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN target
properties are now explicitly initialized in the
qt_set_common_target_properties function, because we don't have access
to the feature in QtSetup.cmake where the CMAKE_<LANG>_VISIBILITY_PRESET
variables were set before.
Task-number: QTBUG-85373
Change-Id: I378453f0e0665731970016170302871e20ceb4e2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
HostInfo is used in places whenever QT_HOST_PATH is set, regardless
whether CMAKE_CROSSCOMPILING is set or not. Make sure that HostInfo
is available when QT_HOST_PATH is set.
Change-Id: I39763a61d77e97dc9c4cc3875bce4deb942f870a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
While trying to implement the 'host artifact reuse' Coin instructions
change, a bug surfaced where the qemu configurations didn't find
the host tools and instead tried to use the cross-compiled tools
while building qtbase, which failed due to not finding the
runtime linker (another unsolved issue).
Before the host artifact reuse change, the host tools were found
successfully.
The difference that caused the issue is that the target install prefix
was a direct subfolder of the host prefix.
host - /home/qt/work/qt/install
target - /home/qt/work/qt/install/target
Before the host reuse change the install prefixes were as follows
host - /home/qt/work/qt/install/host
target - /home/qt/work/qt/install/target
While looking for the Qt6CoreTools package, we temporarily set
CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH to contain first
'/home/qt/work/qt/install' and then '/home/qt/work/qt/install/target'.
CMake then reroots the CMAKE_PREFIX_PATH values onto values in
CMAKE_FIND_ROOT_PATH, making an MxN list of prefixes to search.
Rerooting essentially means concatenating 2 paths, unless the
considered prefix is a subfolder of the root path.
What happened was that the first considered value was
'/home/qt/work/qt/install/home/qt/work/qt/install', a non-existent
location that gets discarded.
The second considered value was '/home/qt/work/qt/install/target.
The second value is the result of seeing that
'/home/qt/work/qt/install/target' is a subfolder of
'/home/qt/work/qt/install' and thus the root path is stripped.
All of this is done in cmFindPackageCommand::FindConfig() ->
cmFindCommon::RerootPaths.
The behavior above caused the target tools be found instead of the
host ones.
Before the host reuse change, both of the initial constructed prefixes
were discared due to them not existing, e.g.
'/home/qt/work/qt/install/target/home/qt/work/qt/install/target'
and '/home/qt/work/qt/install/host/home/qt/work/qt/install/host'
One of the later prefixes combined CMAKE_FIND_ROOT_PATH ==
'/home/qt/work/qt/install/host' + CMAKE_PREFIX_PATH == '/' resulting
in '/home/qt/work/qt/install/host/' and this accidentally found the
host tools package.
We actually stumbled upon this issue a while ago when implementing Qt
5.14 Android CMake support in 52c799ed44
That commit message mentions the fix is to add a "lib/cmake"
suffix to the PATHS option of find_package().
This would cause the subfolder => strip root behavior mentioned
above.
So finally the fix.
First, make sure not to append QT_HOST_PATH in the toolchain file,
there shouldn't be any need to do that, give that we temporarily set
it when looking for Tools packages.
Second, recreate the subdir scenario in the Qt toolchain file by
setting CMAKE_FIND_ROOT_PATH to the current (relocated) install
prefix as usual, but also setting CMAKE_PREFIX_PATH to a new value
poining to the CMake directory.
Aka '/home/alex/qt' and '/home/alex/qt/lib/cmake'.
Third, when a QT_HOST_PATH is given, save 2 paths in the generated Qt
toolchain: QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR. There are the host
equivalents of the target ones above. Use these values when looking
for host tools in Qt6CoreModuleDependencies.cmake, again facilitaing
the subdir behavior.
Note these are currently absolute paths and are not relocatable.
We'll have to figure out if it's even possible to make the host path
relocatable.
Finally as a cleanup, look for the Qt6HostInfo package in QtSetup
strictly in the given QT_HOST_PATH, so CMake doesn't accidentally find
a system Qt package.
Change-Id: Iefbcfbbcedd35f1c33417ab7e9f44eaf35ff6337
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
For repositories other than qtbase the QT_STAGING_PREFIX was empty,
because it was only determined in qtbase.
Also, we save the CMAKE_STAGING_PREFIX in the Qt6BuildInternals package
and set this variable if it's not explicitly set by the user.
As with CMAKE_INSTALL_PREFIX this behavior can be prevented by defining
QT_BUILD_INTERNALS_NO_FORCE_SET_STAGING_PREFIX=ON.
Change-Id: I73100abbef24f5d3fb8f82029d0374176edc8048
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the cache variable QT_STAGING_PREFIX that is the same as
CMAKE_STAGING_PREFIX - if it's set, or CMAKE_INSTALL_PREFIX otherwise.
Use the variable in the places where we check for the emptiness of
CMAKE_STAGING_PREFIX to use CMAKE_INSTALL_PREFIX.
Change-Id: I372d57dfa41818c1965b824c59ab3cac80b38f60
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QT_WILL_INSTALL was set to ON, because an incorrect comparison was
done.
Amends 062318feb2
Change-Id: I201aa2a183563ce05077c36ac2ba3bd61cc827c0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
It wasn't possible to create a cross, non-prefix build with
CMAKE_INSTALL_PREFIX set to something else but the qtbase build dir
and CMAKE_STAGING_PREFIX set to the qtbase build dir.
This would be equivalent to
configure -prefix /usr \
-extprefix ~/my/qtbase/build/dir
Fix this by comparing the qtbase build dir against
CMAKE_STAGING_PREFIX if it is set. We also have to adjust the
QT_BUILD_DIR variable in a similar way.
Change-Id: Iaba5cf0f6954ae4b15d8af1fc62634f5d7f68835
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When cross-compiling, we now create a target_qt.conf file that's to be
used with the host Qt's qmake. With "qmake -qtconf .../target_qt.conf"
projects can be cross-built against the cross-built Qt.
We also create wrapper scripts for the host qmake to save the user from
passing the -qtconf argument.
Fixes: QTBUG-82581
Change-Id: Ib5866e7e820369efea9eb3171e3e3e3ca5c0c3c1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Otherwise the Objective-C++ sources will be built with the default
compiler visibility (visible), and then linked with moc-generated
C++ sources that have the Qt overridden hidden visibility, resulting
in linker warnings such as:
ld: warning: direct access in function 'X' from file 'moc_foo.cpp.o'
to global weak symbol 'Y' from file 'bar.mm.o' means the weak symbol
cannot be overridden at runtime. This was likely caused by different
translation units being compiled with different visibility setting
Change-Id: I22e15e7e181a74de8c0a22c73d06e600e582d7fd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The change fixes the labels to show up correctly in the configure
summary.
It also allows enabling the sanitizer via the feature flags, e.g.
-DFEATURE_sanitize_address=ON.
Finally the qtbase sanitizer option is saved in QtBuildInternalsExtra
so that repos built after qtbase have the same sanitizer options
enabled.
Change-Id: Ic9d9e3ce3c7ebbc244ced2e6d163d1ac8ee06b12
Fixes: QTBUG-84721
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
To be in line with the qmake build we drop the "d" suffix for MinGW
debug libraries unless the debug_and_release feature is enabled.
Task-number: QTBUG-84781
Change-Id: I1b83492bff561d3d7647dde467931ec3866ae940
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Users / developers usually configure a single example. The CI
can still continue to explicitly configure and build all examples.
Task-number: QTBUG-84471
Change-Id: I1c9ac857e7ad0e5602037265194f0a6742386b51
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This patch allows tools to be built for the target platform when the
QT_BUILD_TOOLS_WHEN_CROSSCOMPILING parameter is set at configuration
time.
To avoid naming conflicts, the target tools are suffixed with "_native".
The qt_get_tool_target_name() function can be used to get the tool name
for both scenarios (cross and non-cross compilation).
Extend pro2cmake to refer to the right target name for tools.
The relevant write_XXX functions have a new target_ref parameter that
will be "${target_name}" for tools and literally the target name for
everything else.
Fixes: QTBUG-81901
Change-Id: If4efbc1fae07a4a3a044dd09c9c06be6d517825e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way.
The following story inspired this change.
If a user wants to build a Qt repo into a different install prefix
than the usual Qt one, this will fail configuration because we
look for various things like syncqt, qdoc, etc relative to
CMAKE_INSTALL_PREFIX, which will now point to a different location
where none of the above tools are located.
The intent for such a use case is to support building Qt packages with
Conan, which sets a random install prefix when configuring a repo.
The idea is to derive the qt prefix dynamically from the
QtBuildInternals package location. Essentially it's a reverse relative
path from the QtBuildInternalsConfig.cmake file to the install prefix
that was specified when initially configuring qtbase.
Once the dynamic prefix is computed (so we know where the possibly
relocated Qt is), we can find tools like syncqt and qdoc.
This is an initial attempt to support a use case like that.
More design work will probably needed in case if tools / libs need to
be found in a location different than the Qt install prefix (so
support for multiple install prefixes / search paths).
An example of such a case would be when building qtdeclarative and
qtquickcontrols2 as Conan packages in one go. Most likely the
qmltyperegistrar tool will be located in the random install prefix
set by Conan, so building qtquickcontrols2 might fail due to not
finding the tool in the original Qt install prefix.
As to the implementation details, the change does the following:
- Dynamically computes and sets the
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when
find_package()'ing QtBuildInternals. It's an absolute path
pointing to where the relocated Qt is.
- When building qtbase this variable is not yet available (due
to QtBuildInternalsExtra not existing), in that case we set
the variable to the absolute path of CMAKE_INSTALL_PREFIX
(but only for the initial qtbase configuration).
- Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used
for standalone tests purposes. It's not needed now that we compute
the location of the Qt prefix dynamically.
- The Unixy qt-cmake and qt-cmake-private shell scripts now
use a relative path to find the toolchain file we created.
- The toolchain file also dynamically computes the location of the Qt
packages, and adds them to CMAKE_PREFIX_PATH.
- A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding
tool locations, mkspecs dir, path environment setup for tools, etc.
- Some places still use CMAKE_PREFIX_PATH in the following cases
- When determining paths while configuring qtbase (valid cases)
- When I wasn't sure what the behavior should be, so I left them
as-is (an example is documentation generation, do we want to
install it into the random Conan prefix, or into the main prefix?
Currently it installs in the random prefix).
Note that relocating a Qt installation does not work for non-prefix /
non-installed builds, due to hardcoded paths to include directories
and libraries in generated FooTargets.cmake files.
Task-number: QTBUG-83999
Change-Id: I87d6558729db93121b1715771034b03ce3295923
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The install prefix in such a case is the qtbase build dir,
and not the qt6 top-level build dir. This caused issues with
certain incorrect paths being generated, including a broken
qt-cmake-standalone-test script, as well as upon reconfiguration
determining that a non-prefix build should be installed.
The fix for a non-prefix build is to check explicitly for
the qtbase build dir. This works both for super and non-super
builds.
Task-number: QTBUG-83496
Change-Id: Ida2393176c4c81da767023ff48159afdedfb0a19
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Qt uses the qtNomakeTools() function to mark a directory which will
not be built as part of the default target. This is especially
important when cross-compiling (to iOS for example) because the build
process might fail.
The condition for not building these "GUI tool sub-directory projects"
is the absence of the "tools" value in qmake's QT_BUILD_PARTS
variable.
Introduce a QT_NO_MAKE_TOOLS CMake variable. If the value is true,
it's equivalent to "tools" not being present in QT_BUILD_PARTS.
Introduce qt_exclude_tool_directories_from_default_target().
It's the qmake counter part to qtNomakeTools().
Teach pro2cmake to generate it where appropriate.
Change-Id: If2e5958d91847ab139af0e452608510286e73fa0
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Teaches configurejson2cmake about summaries / reports, so things
like enabled features, configure sections, notes, etc.
Add relevant CMake API for adding summary sections and entries,
as well as configure reports. The commands record the passed data,
and the data is later evaluated when the summary needs to be printed.
This is needed, to ensure that all features are evaluated by the
time the summary is printed.
Some report and summary entries are not generated if they mention a
feature that is explicitly exclduded by configurejson2cmake's feature
mapping dictionary. This is to prevent CMake from failing at configure
time when trying to evaluate an unknown feature. We should re-enable
these in the future.
A few custom report types are skipped by configurejson2cmake (like
values of qmake CONFIG or buildParts).
These will have to be addressed a case-by-case basis if still needed.
Change-Id: I95d74ce34734d347681905f15a781f64b5bd5edc
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Depends on a new bleeding edge feature in as-of-yet unreleased
CMake 3.18, that allows building macOS frameworks using the
Ninja Multi-Config generator targeting more than
one configuration.
It uses the new CMAKE_FRAMEWORK_MULTI_CONFIG_POSTFIX_DEBUG
property which tells CMake to create properly named debug artifacts
in the Multi-Config ninja file.
Without it, both debug and release artifacts would have the same
location (no _debug) postfix, so it would be unclear which file
ends up being compiled as last (the debug or release variant).
Change-Id: I3e10832551731a18317da8f9667d96cec3dc3028
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This feature is read-only. It's controlled by the multi-config feature
of CMake. It mainly exists for the qmake support.
Change-Id: I322459598fe92568eda4d42319ded444537e95d4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This allows doing debug_and_release builds with Ninja on all
platforms.
The "Ninja Multi-Config generator" is available starting with CMake
3.17.
Desired configurations can be set via CMAKE_CONFIGURATION_TYPES.
Possible values: "Release, Debug, RelWithDebInfo, MinRelSize".
For example -DCMAKE_CONFIGURATION_TYPES="Release;Debug".
The first configuration is the 'default' configuration which is
built when calling ninja with no arguments.
To build all targets of a certain configuration use "ninja all:Release"
or "ninja all:Debug".
To build all targets in all configurations use "ninja all:all".
Note that the first configuration influences which configuration of
tools will be used when building the libraries for all configurations.
In simple terms, when configured with
-DCMAKE_CONFIGURATION_TYPES="Release;Debug" the release version of moc
is used by AUTOMOC.
When configured with -DCMAKE_CONFIGURATION_TYPES="Debug;Release"
the debug version of moc is used by AUTOMOC.
Framework builds and Ninja Multi-Config don't currently work together
due to multiple bugs in CMake, which ends up generating an invalid ninja
file with duplicate rules. There are also issues with placement of the
debug artifacts.
This will be handled in a follow up patch after CMake is fixed.
Task-number: QTBUG-76899
Change-Id: If224adc0b71b7d1d6606738101536146aa866cd7
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Tested locally with the following configurations:
- iOS device builds (arm64)
- iOS simulator builds (x86_64)
- iOS simulator_and_device builds (fat arm64 and x86_64 archives)
All iOS builds currently require a custom vcpkg fork which contains
fixes for building the required 3rd party libraries.
qtsvg, qtdeclarative, qtgraphicaleffects and qtquickcontrols2
have also been tested to build successfully.
simulator_and_device builds are also supported, but require an umerged
patch in upstream CMake as well as further patches to vcpkg.
Task-number: QTBUG-75576
Change-Id: Icd29913fbbd52a60e07ea5253fd9c7af7f8ce44c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
