Refactor test adding procedure. It's expected that for each new
platform we prepare test executable and arguments first and then
pass them to common test adding section.
Rename '_qt_internal_wrap_test' to 'qt_internal_create_command_script'
Rework paramerters handling of 'qt_internal_create_command_script',
make them named.
Add 'qt_internal_create_test_script' to add tests and wrap them using
'qt_internal_create_command_script'.
Amends f19266bd02
Fixes: QTBUG-88053
Pick-to: 6.0
Change-Id: I812f4a295005bf3a85cdcb5b8c41180f8249dc96
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt-cmake-standalone-test would be looking for the config files under
the target machine install prefix instead of under the staging prefix
on the build host.
Change-Id: I29850af6d8fe502f4944f689ec10539d17ccdcb9
Pick-to: 6.0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use 'separate_arguments' to explicitly split arguments from environment
that form 'COMMAND' for execute_process. Enclose using bracket syntax
arguments, that propagated to wrapper script as pure strings.
Amends f19266bd02
Pick-to: 6.0
Change-Id: I858ddff7efa281f9cecfda656a02e1fd12361758
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This was needed, when the mkspecs directory was not present in the
non-prefix build directory. That's not the case anymore.
Pick-to: 6.0
Fixes: QTBUG-89182
Change-Id: I2b04c2d857b0af324e1d7c41ed1934a62275d6f1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
There is no point in generating cpp files containing Q_IMPORT_PLUGIN()
macro calls for non-executable targets like modules, plugins and object
libraries in a static Qt build.
It causes unnecessary compiling of 10+ files for each of those targets.
In a static Qt build, plugin imports should only be done for executables,
tools and applications.
Pick-to: 6.0
Change-Id: Ied90ef2f6d77a61a093d393cfdf94c400284c4f0
Reviewed-by: Craig Scott <craig.scott@qt.io>
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>
In some case CROSSCOMPILING_EMULATOR property is not INHERITED and is
set to 'NOTFOUND' by get_test_property. Force it to empty string in
this case.
Add missed 'name' argument to '_qt_internal_wrap_test'. 'name'
previously was used from parent scope.
Pick-to: 6.0
Fixes: QTBUG-88053
Change-Id: I5286bcb9b11659f638e178ce52172dfee994fc34
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>
When a CMake release introduces a new policy that affects most Qt
modules, it may be appropriate to make each module aware of that newer
CMake version and use the NEW policy without raising the minimum CMake
version requirement. To reduce the churn associated with making that
change across all Qt modules individually, this change allows it to be
updated in a central place (qtbase), but in a way that allows a Qt
module to override it in its own .cmake.conf file if required (e.g. to
address the issues identified by policy warnings at a later time). The
policies are modified at the start of the call to
qt_build_repo_begin().
For commands defined by the qtbase module, qtbase needs to be in
control of the policy settings at the point where those commands are
defined. The above mechanism should not affect the policy settings for
these commands, so the various *Config.cmake.in files must not specify
policy ranges in a way that a Qt module's .cmake.conf file could
influence.
Starting with CMake 3.12, policies can be specified as a version range
with the cmake_minimum_required() and cmake_policy() commands. All
policies introduced in CMake versions up to the upper limit of that
range will be set to NEW. The actual version of CMake being used only
has to be at least the lower limit of the specified version range.
This change uses cmake_minimum_required() rather than cmake_policy()
due to the latter not halting further processing upon failure.
See the following:
https://gitlab.kitware.com/cmake/cmake/-/issues/21557
Task-number: QTBUG-88700
Pick-to: 6.0
Change-Id: I0a1f2611dd629f847a18186394f500d7f52753bc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Wrap Qt tests to handle TESTRUNNER and TESTARGS environment variables.
Variables are handled according to qmake build procedure. All test
now are wrapped by generated CMake script.
Fixes: QTBUG-88053
Pick-to: 6.0
Change-Id: I339977ce6ce11ddd38a4bf0bd26eb8f2ae463ba3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We want to remove the Qt .pro files for projects, except examples,
because examples are still meant to build with qmake.
To not lose coverage on examples built with qmake, add instructions that
will build the qtrepo/examples folder with qmake when the CMake
configuration has -DQT_BUILD_EXAMPLES=ON.
This means that such configurations will build examples both with CMake
and qmake.
Aside from making sure that our examples will still build with qmake, it
will gives us some some coverage that a CMake-built qmake works
correctly.
Implementation-wise, add new instructions files that can call qmake and
make depending on configuration and target type.
Pick-to: 6.0
Fixes: QTBUG-85986
Change-Id: Ie8f4cbcda03c94da2aef455e32f48dad41a4bdb0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The qmake build system defines _CRT_SECURE_NO_WARNINGS in
mkspecs/features/qt_module.prf, the cmake build system should do the
same thing in qt_internal_add_module().
Adding this definition can avoid warnings like:
warning C4996: 'strncpy': This function or variable may be unsafe.
As a special case, Bootstrap uses add_library() instead of
qt_internal_add_module(), so _CRT_SECURE_NO_WARNINGS should also be
defined in src/tools/bootstrap/CMakeLists.txt.
Pick-to: 6.0
Change-Id: Ic82193d177f82785fd84948efa78c49ca8d8db46
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
I'll preface by saying, it's not clear to me why the behavior is
different.
Our qt_run_config_test_architecture function builds a target
executable, and then uses file(STRINGS) to try and parse out some
magic strings that we expect the executable to have (architecture,
abi, etc).
In qmake this was done by matching with a regular expression ending on
a \\0 null byte character.
In CMake, we do a string(FIND) and string(SUBSTRING until the end of
the line) on a *line* returned from file(STRINGS). Notably, I did not
find any regexp syntax provided by CMake to try and match a null byte
character.
Note the docs for file(STRINGS) implies to me that *lines* are
detected by looking for newline characters '\n'. The docs also
mention that binary data in the file is ignored. What's binary
data though?
If you open the executable with a hex editor, at least on macOS, the
strings we are interested in are indeed separated by null byte chars,
not newline chars.
On most platforms file(STRINGS) did end a line on the null byte
character.
Except, for some reason not when building Qt for the oss-fuzz project
with clang under Docker.
Calling message() on one of the lines prints a very long string with
null characters seemingly replaced with semicolons, and of course the
matched architecture string is wrong and fails configuration.
For *some reason*, if I add a "REGEX ==Qt=magic=Qt==" option to the
file(STRINGS) command, the captured output lines don't contain
semicolons even when building for oss-fuzz.
The extracted strings are then correct, and configuration succeeds.
Use the REGEX option workaround, with the aim to quickly fix Qt
building for oss-fuzz for 6.0.1 release.
Pick-to: 6.0
Fixes: QTBUG-89047
Change-Id: Iad11c1090c1187aadd39082f196050bf3290df95
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
QMake libraries that contain dashes are referenced by QMAKE_USE as is,
but the corresponding QMAKE_LIB_<NAME> variable must be normalized to
contain underscores.
Example from the qmake build:
./mkspecs/modules/qt_lib_waylandclient.pri
11:QT.waylandclient.uses = wayland-client xkbcommon wayland-cursor
./mkspecs/modules/qt_lib_waylandclient_private.pri
12:QMAKE_DEPENDS_WAYLAND_CURSOR_CC = WAYLAND_CLIENT
13:QMAKE_DEPENDS_WAYLAND_CURSOR_LD = WAYLAND_CLIENT
15:QMAKE_LIBS_WAYLAND_CURSOR = -lwayland-cursor
Pick-to: 6.0
Change-Id: If31bd45764d52f97d80d6388503008dc1ffb16ab
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Which is probably the direct port of -nomake XXX, as qmake
always offered the way to build tests/examples/etc. after
configuring without, while cmake doesn't.
Pick-to: 6.0
Change-Id: I85b039e56cde3ddfaf661385100d3c3a8cc2ac16
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Those entries were always empty. The INTERFACE_QT_MODULE_USES property
was never set.
Map each public dependency to its qmake lib name and place this value
into the module's QT.<module-name>.uses variable.
Take into account the "_nolink" target modifier and translate it to
qmake's "/nolink".
Pick-to: 6.0
Fixes: QTBUG-88951
Change-Id: Ib6ef65b842a1fe1da3ade55867583343b4ee76ee
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Rename QT_QMAKE_LIB_TARGETS_foo to QT_TARGETS_OF_QMAKE_LIB_foo, because
we want to introduce the counterpart QT_QMAKE_LIB_OF_TARGET_bar in a
subsequent commit.
Pick-to: 6.0
Task-number: QTBUG-88951
Change-Id: I33f00f4fe65c5977da6e74c632ebeab3b891c89a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Consider a qmake lib 'foo' that doesn't have entries in
QMAKE_LIBS_FOO. Then we must not discard this entry in the generated
module pri file, because otherwise any attempt to QMAKE_USE 'foo' will
fail with the error message "Library 'foo' is not defined.".
Pick-to: 6.0
Task-number: QTBUG-88951
Change-Id: Ibed283857f5f66b1b79459fe7b7cf06c7ce0691d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add '_qt_internal_dump_expression_values' function that dumps all
values evaluated by 'qt_evaluate_config_expression'.
'_qt_internal_dump_expression_values' doesn't evaluate undefined
features, only collect actual values.
Fixes: QTBUG-88476
Pick-to: 6.0
Change-Id: I9d09ffbd9f9fa91bc4f36536c58e7f118b06f9b9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Despite being installed in the the binary directory, this
CMake snippet cannot be executed.
Pick-to: 6.0
Change-Id: Ibfd31e51184f0688d19ac063804cc200c95555a7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before this change, the prl files always assumed that resource object
files are installed into $qt_prefix/lib when doing a prefix build.
That was true for qt_internal_add_resource calls, but not for
qt6_add_qml_module and qt6_target_qml_files.
Change qt_internal_record_rcc_object_files to take a new required
INSTALL_LOCATION argument. The argument takes a path relative
to CMAKE_INSTALL_PREFIX.
Modify __qt_propagate_generated_resource to save the relative path of
the generated resource source file, which will be used in the
computation of the final resource object file location.
This is needed because the Qml resource functions place the source
files in a different directory layout, e.g. .rcc vs .qmlcache
Modify qt_generate_prl_file to prepend $$[QT_INSTALL_PREFIX]/
instead of $$[QT_INSTALL_LIBS]/ for the resource install paths.
A follow up patch is done in qtdeclarative to pass the new
INSTALL_LOCATION argument from the Qml CMake functions.
Amends f9dcade5e7
Task-number: QTBUG-87702
Task-number: QTBUG-88425
Change-Id: Id17bb517b4cb5d00911bfd10a728ba4e0d44871b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
(cherry picked from commit 54d0ca93bca78f8fd31b6761f078e7a96283f183)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Follow the pattern recommended in the CMake docs for the $<JOIN:...>
generator expression. Wrap it in a $<BOOL:...> genex so that if a
target's INCLUDE_DIRECTORIES property is empty, we don't add a
stray -I with no directory following it. This fixes the following error
when running qdoc:
qdoc: Missing value after '-I'.
Pick-to: 6.0
Task-number: QTBUG-88838
Change-Id: Ie3ef2625fbb29cc501f7fc22ff7a9cc8ac548322
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If CMake version is 3.19 or greater, use cmake_language(DEFER CALL)
for Qt internal scope finalizers, instead of the homegrown
implementation.
Apart from not depending on the hacky homegrown solution, it
significantly improves the readability of --trace-redirect logs.
Pick-to: 6.0
Task-number: QTBUG-77377
Change-Id: I5ce374bb313865662c536826e86052bc762438b9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
On DLL platforms, the value of QMAKE_PRL_TARGET should be the import
library (foo.lib), not the actual DLL (foo.dll). The genex
TARGET_LINKER_FILE_NAME provides exactly that.
Fixes: QTBUG-88864
Pick-to: 6.0
Change-Id: I553930bb840007772fe8f4612f95e0e320f54107
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before CMake 3.19, we are not allowed to query non INTERFACE_ prefixed
property names from INTERFACE libraries. And it was the wrong thing
to do as well. Prefix the properties with INTERFACE_ as appropriate.
Don't try to add INTERFACE_COMPILE_DEFINITIONS from header only
modules to the headerclean compile commands. This causes configuration
issues with UiPlugin in qttools. Fortunately it seems that qmake
doesn't do that for 'header_module's either.
Finally don't query for the FRAMEWORK property on the passed target
(INTERFACE libs can't be frameworks). Instead just query if the whole
Qt build itself is a framework build.
An issue was discovered regarding QT_NO_ENTRYPOINT genexes breaking
headersclean add_custom_commands for UiPlugin in qttools. To avoid
this the property was renamed to all lower case in
6ca66de9120537134b63d42de6c53c6e5834e8f3. This avoided the immediate
issue, but it's possible it might resurface in the future with a
different property name that wasn't renamed. In particular I thought
it might happen with QT_NO_UTF8_SOURCE but it didn't.
In case something like that happens again, the two possible solutions
are to bump minimum CMake version requirement to 3.19 (where upper
case property names are allowed to be queried from INTERFACE libs) or
to implement recursive include directory fetching similar to our
qt_internal_walk_libs implementation.
Pick-to: 6.0
Task-number: QTBUG-86053
Task-number: QTBUG-82615
Change-Id: I7815d555ec9ea049a8fd40f2a2f072dcb9f5e9c3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Query the include dirs from the INTERFACE_INCLUDE_DIRECTORIES property
when generating docs for an INTERFACE library.
Amends 2db41fefa0
Pick-to: 6.0
Task-number: QTBUG-88838
Change-Id: Ic8a454ba66b2dbc59bad883e1e0d38ebb26d0370
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Restore 'QT_STAGING_PREFIX' logic when generating
'qt-cmake-standalone-test'. Relative paths now calculating depend on
'QT_STAGING_PREFIX'. For prefix builds QT_STAGING_PREFIX should be
prepend to '__qt_cmake_standalone_test_path'
Fixes: QTBUG-88764
Pick-to: 6.0
Change-Id: I655c60847f2ab872948cfe9aedc27835e5cc4fb5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...and include it in QtBuild.cmake.
Commit e8d8b1a5e4 added two different code paths to include
QtBuildInternalsAndroid.cmake.
This was needed, because:
In a top-level build, we must not include files that are not yet
installed. We have the source tree available, and
"${QT_SOURCE_TREE}/cmake" is in CMAKE_MODULE_PATH.
We can use the "module syntax" of the include() command.
In a per-repository build, when building against an installed qtbase, we
must not include files of the source tree, because that's not guaranteed
to be available. However, Qt6BuildInternalsConfig.cmake is installed,
and we can directly include QtBuildInternalsAndroid.cmake, which is
right next to it.
We can circumvent this whole issue by moving the Android-related
functions out of the Qt6BuildInternals package and including it in
QtBuild.cmake.
Pick-to: 6.0
Task-number: QTBUG-88718
Change-Id: I5192ba19bb77952505c20d053d7285f798d16ac5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Commit 9e0fb9c4fb introduced build
failures in non-top-level builds when building Qt modules against
qtbase.
This was observed on in the CI for CentOS.
Partly revert above commit by taking the old code path for non-top-level
builds.
Fixes: QTBUG-88718
Change-Id: I8926e1e4628ec5bdcea99e10497c1f65c10d072d
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
(cherry picked from commit 510186a218e63c88100efc38cb1611f122f94570)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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>
Plugins will no longer get .pri files generated in non-static builds.
Header modules are now marked in the .pri files as CONFIG += no_link.
Pick-to: 6.0 6.0.0
Fixes: QTBUG-88221
Change-Id: I06e31fa970ad021261c43ca3acd88055cc4c9555
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
During a top-level prefix build, while configuring qtsvg,
Qt6BuildInternalsConfig tries to include QtBuildInternalsAndroid.cmake
but such files are not copied by qt_copy_or_install() at configure
time.
We need to use the "module" form of include() to take CMAKE_MODULE_PATH
into account. Then QtBuildInternalsAndroid.cmake can be loaded from the
source tree.
The include's current form was introduced in commit
3cb9ee3a5b without further
explanation. Assuming an accidental change.
Pick-to: 6.0 6.0.0
Task-number: QTBUG-88460
Change-Id: If06ac715fae3c2bebbeffca44b7e07265ffb0f71
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Move 'INPUT_' variable detection logic out of
'qt_feature_set_cache_value' function. Use 'INPUT_'
variable to enable/disable related 'FEATURE_' in case if
'FEATURE_' is not defined.
Fixes: QTBUG-88501
Pick-to: 6.0 6.0.0
Change-Id: I1162ac0fb562036898a37b52c3f80229ec8a0970
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add a target for each level-1 subdirectory in a module. Ninja already
generates phony targets such as "qtbase/src/all", but those are not
available in e.g. IDE integrations of CMake. With this addition, targets
like qtbase, qtbase_src, and qtbase_tests are available in IDEs.
Pick-to: 6.0 6.0.0
Change-Id: If1c3369e9413b3ce127e68c443d4d22949708d5e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For shared build, Qt6BundledHarfbuzz.lib and Qt6BundledPcre2.lib are not
installed. But their pri files(qt_ext_harfbuzz.pri, qt_ext_pcre2.pri)
and debug info files(Qt6BundledHarfbuzz.pdb, Qt6BundledPcre2.pdb) are
still installed. These files should not be installed too.
Pick-to: 6.0.0 6.0
Change-Id: I3e54bec01d94ee3897b485a982d01b24edc602aa
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Updates due to newer compiler version in QNX7.1
Task-number: QTBUG-88300
Change-Id: If9bbc08d49a077d80174a1807e069b5d4ef61c0d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use lowercase underscored property names. This ensures they will
continue to work even for INTERFACE libraries if it ever comes to
that.
Change-Id: I5281070f25c1eb9f591c79af8b7fa6169c7c0fb7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This function will be used by qtdeclarative CMake functions to record
resource object file information for Qml-specific generated resources
(like the ones containing qmldir and qml files).
Task-number: QTBUG-87702
Change-Id: I17c295821775d005dea82d9fbdf83d7ee613f615
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The CMake build of Qt intends to improve the developer experience in
regards to static Qt builds and Qt resource files. Specifically with a
CMake build of Qt, Qt developers don't have to manually call
Q_INIT_RESOURCE anymore.
For details see the following commits
e343affd63e817ac3d684ab5432081
The last commit's implementation is incomplete though.
To ensure successful linking, each target's prl file should contain
not only the resource object files that are assigned to the target,
but also all resource object files of the target's dependencies.
To achieve that, qt_collect_libs will now recursively collect all
resource object files assigned to the QT_RCC_OBJECTS property of each
dependency.
Note this implementation is still incomplete. We do not export rcc
object file information in the CMake Targets files.
That means that when configuring qtdeclarative in a
non-top-level build, the generated Qml prl file will not
contain references to Core's mimetypes resource object file, etc.
So with the current change, only the object files that are part of the
current CMake configuration build are tracked.
Exporting the resource object files locations proves in a format
usable for prl files proves to be difficult (due to CMake not
supporting exporting genexes in random properties) and will have to be
addressed in a separate change.
Amends 4ab5432081
Task-number: QTBUG-88425
Change-Id: I546655bdfdf7aa86a8df9aadfc054fa415130a33
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Refactor the function in preparation of processing rcc object files.
Introduce 2 new functions to get and set values in the memoization
dictionary used by qt_internal_walk_libs.
Modify qt_internal_add_target_aliases to assign the alias names it
creates as properties on the target.
Extract these aliases when available to assign memoized values not
only for the initial library name, but also for its aliases.
When recursively calling qt_internal_walk_libs, make sure to provide a
unique out_var name based on the outer target name, and not just
lib_libs. Otherwise the out_var values would be polluted from
previous recursion runs.
Make sure to check for -NOTFOUND in if() checks so that we reuse
memoized values that are the empty string.
Change-Id: I8fd8e2b0ae14d0ba8f502bc5a764d6e01095001a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In qt_internal_create_module_depends_file we're checking the target
property INTERFACE_MODULE_HAS_HEADERS. However, this property is not
exported, and in per-repo builds we do not have access to this.
As we cannot export INTERFACE_* properties, we export another one,
called _qt_module_has_headers.
This amends commit 598e873c84.
Fixes: QTBUG-88503
Change-Id: I04b3e24add6e95b577a049c80683b7361ff72f59
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make paths in qt-cmake-standalone-test relative to script's PWD.
Fixes: QTBUG-88380
Change-Id: I6ab507c31ebed391f4e85bc6fe3f7f747dd97d54
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Without breaking currently generated CMakeLists
Fixes: QTBUG-88549
Change-Id: Ibda643e1374d9024bf693c12de8ec0ac46e09b7b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
That breaks configuration with CMake version 3.18.x (but not 3.19 for
some reason).
Specifically configure ends up passing -DCMAKE_CXX_COMPILER=clang++
which overrides the compiler set by the CMake Android toolchain file,
and at the very end of CMake's configuration it complains about
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_CXX_COMPILER= clang++
Which suddenly starts another configuration with the modified
compilers, ends up detecting host compilers and libraries and
basically everything breaks apart.
Fix QtProcessConfigureArgs.cmake not to pass the compiler options if
the mkspec contains 'android'.
Who knows, we might need this for other platforms too at some point.
Task-number: QTBUG-88460
Change-Id: Idd57870a7cb1009a4e7802e5b3d5ac735f2dacf6
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Although many executable files were generated by qt_internal_add_tool().
Some executable files like designer and androiddeployqt were generated
by qt_internal_add_app(). Some executable files like windeployqt were
generated by qt_internal_add_executable(). For these executable files,
their PDB files won't be installed on MSVC platform, and their separate
debug info won't be generated and installed on other platforms.
To fix this, qt_enable_separate_debug_info() and
qt_internal_install_pdb_files() should also be called in
qt_internal_add_executable().
Fixes: QTBUG-88268
Change-Id: Id6a3b5842dba325166e3d696701c82ad942bca74
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Updates one 3rdparty CMake file from
https://github.com/KDE/extra-cmake-modules to include support for
fuzzing.
Task-number: QTBUG-88429
Change-Id: I19e7ed3c5602c34ba4b86e6b0df2ea3047c7c9e6
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In multi-config build, for different configs, the pdb files of EXEs
should have different installation directories.
For example, when CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug,
<build_dir>/bin/moc.pdb will be installed to <install_dir>/bin/moc.pdb.
<build_dir>/bin/Debug/moc.pdb should be installed to
<install_dir>/bin/Debug/moc.pdb, not <install_dir>/bin/moc.pdb.
Fixes: QTBUG-88268
Change-Id: Idc7c92ca8d44bb81d990656af2b309306a4f5c6b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Android *.so files need to CXX visibility to default after
qt_set_common_target_properties() which was setting it to hidden.
Also, pass the correct androidtestrunner arguments for cmake check
target
Fixes: QTBUG-88228
Change-Id: Ia29cdc9e65153c9669f3ec06f74a46f8fcd8c507
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The EntryPoint interface target now contains all the logic
for what flags and optional static libraries to add when the
entrypoint is enabled.
The target property QT_NO_ENTRYPOINT can be used to disable
the entrypoint.
Change-Id: I9b14ff729366cd6307789c969ebd4b2ca19de77d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Fix the overly strict regex in qt_internal_create_module_depends_file to
allow for - and _ in module names.
We had the above mentioned dependency cycle, because the module name
Core_qobject was translated to just Core, creating a Core -> Core
dependency.
Amends da7609e7d0.
Fixes: QTBUG-88437
Change-Id: I866f7ce31e9a1b92fe4c0a6450295c2f3c761558
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Since feature evaluation expects explicit 'no' value for INPUT_opengl
to disable either desktop or es2 opengl support, add special
processing for -no-opengl option into QtProcessConfigureArgs.cmake
Task-number: QTBUG-88142
Change-Id: Ib49123ee3e9f98035f6ec85a182382559f4db478
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
All configure arguments should be processed as strings
and not be ignored if they satisfy CMake's FALSE criteria
(see https://cmake.org/cmake/help/latest/command/if.html)
Fixes: QTBUG-88424
Change-Id: I932038ad3c5999bed58957dec51fbf892bd650d7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This reverts commit 9968a211f9.
The PKG_CONFIG_* environment variables should be added by the user
environment, preferably by the toolchain file.
Apparently, the change was added for Android before we turned off
pkg-config for Android. It is not needed anymore.
Change-Id: Ieeed09ae53a606c85d4937f463286b5b0f76bde9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
According to Microsoft's docs, /OPT:ICF is enabled by the
linker by default unless /OPT:NOICF or /DEBUG is specified.
If we are in RelWithDebInfo mode, /DEBUG is passed to the
linker to generate debug symbols, however, it caused the
identical COMDAT folding be disabled. We now pass /OPT:ICF
to the linker explicitly to prevent this.
[1] https://docs.microsoft.com/en-us/cpp/build/reference/opt-optimizations?view=msvc-160
Change-Id: I02099edb81034ace7bb19f1164d57829e3979a5f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We need to handle the possibility of versioned dep (Qt6::Foo).
Change-Id: I66797dbc59f00500892958e9c99c4555cddcb980
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If not, the resulting dep would end up as 'Foo>', but we need 'Foo'.
Change-Id: I246b66eb0ac6b076eea200c4d1ad84bba8ed179c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
*Not* using /permissive- exposes Qt and client apps to interesting
bugs and/or build failures, (e.g. QTBUG-87225, or
19b5520abf). We demand strict
conformance by any other compiler, it's time to demand it from
MSVC too.
The Windows headers themselves are clean starting from the
Windows Fall Creators SDK (10.0.16299.0), and moreover Qt 6 will
drop WinRT; therefore, the comment in the mkspecs does not apply
any more.
Since /permissive- implies /Zc:referenceBinding, drop that
option. The other implied options are set on MSVC < 2017,
but I leave them in to avoid tinkering with the fragile lists
of C/C++ flags.
Rename the CMake internal helper function to better describe
what it does.
Fixes: QTBUG-85633
Fixes: QTBUG-85637
Fixes: QTBUG-85635
Fixes: QTBUG-88244
Change-Id: Ie03fddb61aa066fdc14b7231c22e7108b4a02fbb
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In the qmake-based build, the hostdatadir is the directory where "Data
used by qmake" is located. In the CMake build the equivalent is
INSTALL_MKSPECSDIR. Create the mapping accordingly.
Fixes: QTBUG-88211
Change-Id: I9e3d1af24bc7f41333ef2269fced5ab3fcfa848d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously, QtDocsHelpers.cmake was invoking CMake to copy
files or directories instead of using installation targets.
This resulted in DESTDIR being ignored.
Now we create installation targets and ask CMake to
install them.
Change-Id: Idbc79d47a37f9ca865d28543bdbbdde3ba448fa3
Fixes: QTBUG-87382
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Extend qt_configure_get_padded_string to make the feature list look like
qmake's.
Fixes: QTBUG-88144
Change-Id: I714f2b2f3537b506365a03b5b6bc3413e9cab167
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
In configure we need to set the Release configuration first to make it
the main configuration.
Change-Id: I5fe744b0dcea009c4d672bf519b38c80c87475dd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In multi-config builds (which equals the debug-and-release feature) we
exclude tools of the non-main configurations from the default build.
But we still create installation rules for them. Mark those as optional
to avoid "cmake --install" yielding errors if those tools weren't built.
Fixes: QTBUG-85411
Change-Id: Ic2d3897d1a1c28a715d9a024ec8606fff00e0315
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make zstd config based lookup quiet and check for version variable
as required for ZSTD target.
Add IMPORTED_LOCATION by default for pkg-config based search.
Expect that select_library_configurations will set correct value
for ZSTD_LIBRARY.
Fixes: QTBUG-88091
Change-Id: Ia5079154ce4fc4eefbc0931317219b5ca0f3f82f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Modify pro2cmake converter to add extra argument to
qt_internal_add_plugin. DEFINE_IF FALSE is added to generic plugins
those had "PLUGIN_EXTENDS = - " specified in .pro files.
Fixes: QTBUG-87861
Change-Id: I9269df19a32a088f5261f50e7ffff6d29c3d605f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The QT.foo.module entry is used for linkage, so we shouldn't
add it for header only modules.
Change-Id: Ibb6e7ab08083ccab11d7e060f35c54153e3751c0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For non-cross-builds, qt-configure-module is located in
CMAKE_INSTALL_PREFIX/bin, not below the staging prefix.
Fixes: QTBUG-88262
Change-Id: Ib6cdd88ece391d5b8ce850b991564e5bed1e475d
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>
Trying to locate zstd package configuration prior to use pkg-config.
Define explicit IMPORTED_LOCATION_DEBUG and IMPORTED_LOCATION_RELEASE
in case of pkg-config usage.
Fixes: QTBUG-88091
Change-Id: I3cb86a66fad4e7b78b3d2fcff061508fc25e25a7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use select_library_configurations to select applicable libraries
set for PCRE2.
Fixes: QTBUG-88092
Change-Id: I11e669a0142d53a3c344c86bd1d8eb797df4ba97
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Some repos (like qtimageformats) might not have Qt modules, but they
still need a target to pass to qt_internal_add_docs().
Allow passing custom targets to qt_internal_add_docs() without trying
to generate bogus include paths.
Change-Id: I12191e5b16c082e62e40c96d0eb4d6c0256e7ea4
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
"ninja install_docs" should not run the "docs" target, because with
the usual workflow
ninja docs
ninja install_docs
the documentation would be built twice.
That of course means that "ninja install_docs" will fail if "ninja
docs" wasn't run before.
Analogous for html_docs, qch_docs, the repository-level and
module-level documentation targets.
Change-Id: I8ad83602dd393b5afc79a19ab3d395987c889d0d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The following targets did not do any actual installation:
install_docs, install_html_docs, install_qch_docs,
plus their repository-level counterparts.
Add the following dependencies:
install_html_docs
--> install_html_docs_<repo>
--> install_html_docs_<module>
Analogous for qch.
The install_docs target already triggers install_html_docs and
install_qch_docs. Analogous for install_docs_<repo>.
Fixes: QTBUG-86738
Change-Id: I3468e000e050e2787a859e61d40161f5459cb351
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Tools and library DLLs already have version information embedded.
Add the missing _qt_internal_generate_win32_rc_file call for plugins.
Fixes: QTBUG-87747
Change-Id: I619948f4066ce229d41e8b93f125751e1d28e26c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
INPUT_ variables enable FEATURE_ variable only in case if valid
"true"-like value is assigned from command line.
Amends dc43061e9a
Fixes: QTBUG-87755
Task-number: QTBUG-88142
Change-Id: I65e85c7548981fdec94366b531f6df6396be71b7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We have some cache variables that are used in our qt.toolchain.cmake
toolchain file, for example QT_CHAINLOAD_TOOLCHAIN_FILE. When CMake
runs a configure test with try_compile, our toolchain file is included
again, but only a restricted set of variables is available.
Add the variables that are used in our internal toolchain file to
CMAKE_TRY_COMPILE_PLATFORM_VARIABLES. This makes them visible for
try_compile calls operating on source files.
Also pass the variables via the environment to support try_compile
calls that operate on whole projects.
Fixes: QTBUG-87873
Change-Id: Iebca9e23686bec5072194b15482e1782b9367a0e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
These were omitted in the original change, which cause cmake builds to
fail configuring
Change-Id: I37996099aaa0d912ce06b1f06c175cc5cf159e33
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This matches how it is in the qmake mkspec, silencing a lot of
warnings - but contrary to when building with qmake, it's only
applied when building Qt itself. For external projects built with
cmake, the Qt headers are included with -isystem, which silences any
warnings from those headers.
Change-Id: I1a498d3c2715cb73e647668cb7226ceeffb7ff0b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Now all shared libraries and executables will get .debug files on
the platforms that support FEATURE_separate_debug_info
With the directory property _qt_skip_separate_debug_info certain
targets can retain the debug symbols in the binary e.g. lupdate with
MinGW 8.1.0 will cause objcopy / strip to fail.
Fixes: QTBUG-87015
Change-Id: I03b106e68ef0a42011d1ba641e6f686b2e7b7fb4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
"configure" script translates feature-related parameters to INPUT_
variables instead of FEATURE_.
Both INPUT_ and FEATURE_ variables passed to cmake script are
equivalent. FEATURE_ has higher priority in case if both are defined.
Fixes: QTBUG-87755
Change-Id: If697a0d62ab839877a3196ea74e631582a570dda
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We must write config.opt in the same directory we're reading it from.
We must not write the -top-level argument to config.opt.
This amends commit 2a29426e39.
Change-Id: I96da9094579fec29c290411677d6b538878399f4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add a new function that returns the minimum CMake version required to
build Qt. Pass that value to cmake_minimum_required() when building
qtbase and its standalone tests.
The minimum supported CMake version is read from qtbase/.cmake.conf
and its value should be updated when the need arises. It's the main
source of truth for all repos.
Provide a way to lower the minimum CMake version at configure time by
passing a value via QT_FORCE_MIN_CMAKE_VERSION.
This is not an officially supported way of building Qt. If the
specified version is lower than Qt's supported minimum, show a
warning.
Nevertheless the option is useful for testing how Qt builds with a
different minimum CMake version due to different policies being
enabled by default.
Issue warnings for CMake versions that are higher than the minimum
version but are known to cause issues when building Qt.
A counterpart change is needed in qt5 to ensure the minimum CMake
version is set at the proper time for top-level builds.
Ideally we would use the same 'check the CMake minimum version` code
in all our repositories, but that will cause lots of duplication because
we can't really find_package() the code and doing something like
include(../qtbase/foo.cmake) hardcodes assumptions about repo
locations.
So for now we don't bump the minimum version in child repo
cmake_minimum_required calls (qtsvg, qtdeclarative, etc).
Instead we record both the minimum supported version and the computed
minimum version (in case a different version was forced) in
QtBuildInternalsExtra.cmake.
Then we require qtbase's computed min version in
qt_build_repo_begin().
This won't set policies as cmake_minimum_required would, but at least
it propagates what minimum CMake version should be used for child
repos.
We might still have to bump the versions in child repos at some point.
Task-number: QTBUG-88086
Change-Id: Ida1c0d5d3e0fbb15d2aee9b68abab7a1648774b9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The flags go before the library in the final linker line, as opposed
to the dependencies declared in LIBS.
This allows us to declare the flags for the entrypoint
in the project file of the entrypoint, instead of in
a standalone prf.
Change-Id: I35c054fe9fdaa6add7cd0e8ba3f7304f975ff80f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
On the qmake-side we had exports, but they were quoted.
Change-Id: I95af4b927079691cab6403fec850f345ba181a00
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The arguments -platform, -xplatform and -device determine the mkspec
that's used for the qmake companion files.
If the user specifies a mkspec that indicates usage of clang or icc,
set the respective CMake variables to use one of those compilers.
Fixes: QTBUG-87836
Change-Id: I2b10d819b0eb92a97d7f79672547b1e2d821cf33
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
At the moment our examples require a minimum of 3.14 due to changes
in upstream CMake's Autogen functionatlity to support Qt 6. Anything
lower would simply not work with Qt 6.
It's not clear yet if we actually want to require 3.14, or something
higher. At the very least there were many significant changes to
support iOS in CMake 3.15.
But for now just bump the version checked by Qt6Config.cmake to be
consistent with what's in our examples.
Task-number: QTBUG-88086
Change-Id: I119c2ad05a18c357fe7c659b30685af87475fc84
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
1. clang-cl doesn't support "-fno-exceptions", it uses msvc's parameter.
2. some parameters supported by msvc are not supported by clang-cl
and they are causing huge warning message flood, don't add them.
3. use correct optimize parameter for clang-cl.
Change-Id: Idbadf139127143c5fa6c49068588cb26f47da7a2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When linking static libraries, MSVC's link.exe complains about
the unknown parameter "/INCREMENTAL:NO" and output a lot of warning
messages about this. This doesn't happen when it's linking exes
or dlls.
The situation is a lot more worse when we are using clang-cl.
clang-cl will print some error message like it can't find a
file named "/INCREMENTAL:NO" and just stop compiling. It seems
clang-cl treat unknown parameters as input files.
Fixes: QTBUG-87875
Change-Id: I37ed29de082b0258e81494db54f275417ab42708
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The QT.<module>.DEFINES assignment in pri files needs to take into
account the module name when computing the define name. This is the
MODULE value that qmake specifies.
In CMake that would be the value of CONFIG_MODULE_NAME.
Previously the value of the define was computed in
qt_internal_module_info() without taking into account the module name.
While qt_internal_module_info() ended being used also for plugins and
other target types, the defines computed by it were meant to be used
only for Qt modules.
Thus remove the <result>_define assignment from
qt_internal_module_info and move its computation directly into
qt_internal_add_module, taking into account the value of
CONFIG_MODULE_NAME.
The only other use of module_define was in qt_internal_add_plugin but
that was merely a long overdue copy-paste error, qmake doesn't
propagate QT_FOO_LIB defines for plugins.
As result, a define special case in testlib is not needed anymore,
because the define is now computed properly.
Finally, QT_FOO_LIB should not be used while building the Qt module
itself, so instead of using PUBLIC_DEFINES option of
qt_internal_extend_target, use target_compile_definitions(INTERFACE)
directly.
Change-Id: I4d44f7461bac2f0c09aec3e995d02dfe36e00883
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Makes the diff between Qt 5.15 and 6.0 easier to read, to see what's
missing.
Change-Id: Idf8aa17b3ab8494f6855c172665423a53ca8a024
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We do not have host-specific INSTALL_*DIR variables in the CMake build.
It is equivalent to a qmake build with host prefix = prefix.
Change-Id: I65731e6038508b6c28e3f2819b624ba19abfc82a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The value of this variable must be exactly "mkspecs" or end with
"/mkspecs".
Change-Id: I39f83e9660794dfe23f5fd39fb1084b87ba1f140
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The value of this variable - whithout the mkspecs part - is what's
called the host data dir in Qt5.
Fixes: QTBUG-87681
Change-Id: I3dfeed17e8a614476aef4d9c651a141ce62e6551
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We must escape backslashes in CMake code that's to be evaluated and in
the arguments we read from config.opt.
Change-Id: I65d033c77f71888974983aa3d834acb2fe89f3fb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Passing arguments with equal signs was broken for configure.bat and
qt-configure-module.bat. An argument FOO=BAR was split at = and written
as
FOO
BAR
to config.opt, breaking every attempt of assigning CMake variables.
We must not iterate over %* in batch files to avoid splitting arguments
at equal signs. Instead, pass %* unmodified to a CMake script that
writes config.opt.
Fixes: QTBUG-88019
Change-Id: I7c743a206961d1ed168f2313f864905f6b345b49
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In a subsequent change we will call another CMake script from
qt-configure-module.bat. Write the location of qtbase/cmake into the
generated scripts instead of the path to QtProcessConfigureArgs.cmake.
Change-Id: Ie333b16d310b215c6e49efa27740c7525453d28f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMake considers ON/OFF as booly string values regardless of the case.
Make the value comparison in QtFeature.cmake case-independent.
It's now possible to build Qt with '-DFEATURE_gui=off'.
Fixes: QTBUG-87948
Change-Id: I3d948e8219ad9728414803c8c4cd756034073b46
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Rolf Eike Beer <eb@emlix.com>
Previously we determined if a library represented by an absolute path
is a Qt module by checking if it's located in the build dir of the
current repo.
That is not sufficient for non-qtbase prefix builds, where
a Qt module might link against both a module in the current
build dir and in the prefix dir.
Detect such cases, and rewrite the absolute paths to relocatable paths
(either framework flags or paths starting with $$[QT_INSTALL_LIBS].
This should fix building examples with qmake that use QtQuick.
Fixes: QTBUG-87840
Change-Id: Icaf8f1a7c66292c80662fd0d5771a5a1628a9899
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add an EXTRA_CMAKE_FILES argument to qt_internal_add_tool()
that allows tools to install an additional Macro.cmake file.
This is modelled after similar functionality in qt_internal_add_module.
Task-number: QTBUG-87870
Change-Id: I80838b8966f1018fdd379b1da877b6bc418de075
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Fixes a regression introduced in commit 748b3b9c89 for builds
that are both not a QT_SUPERBUILD and not QT_WILL_INSTALL.
Change-Id: I52b920176a2696fa6206b89b2b69ae1a7f3fbc25
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The top-level prepare_docs target is supposed to run before the
generate_docs target.
The repository-level targets like prepare_docs_qtbase now also run
before their respective generate targets.
To achieve that, several intermediate targets had to be introduced.
The dependencies for top-level generate_docs look like this:
/--> generate_top_level_docs_Core --\
generate_docs ---> generate_top_level_docs_Gui -----> prepare_docs
\--> ... --/
The dependencies for repo-level generate_docs_<repo> look like this:
/--> generate_repo_docs_Core
generate_docs_qtbase ---> generate_repo_docs_Gui
\--> ...
generate_repo_docs_Core --\
generate_repo_docs_Gui -----> prepare_docs_qtbase
... --/
Analoguous for qch_docs.
And last but not least, the module-level generate_docs_<module> depends
on prepare_docs_<module>, just like before.
The strangely named top-level install targets have been renamed to
install_html_docs, install_qch_docs and install_docs.
The html_docs target is now merely an alias for generate_docs.
Apart from prepare_docs, the top-level targets do not depend on the
repository-level targets anymore. Targets that are just an alias (docs,
install_docs, ...) have been re-defined to depend just on the respective
top-level targets.
Fixes: QTBUG-87758
Change-Id: I24466d3a252d518a30a2064bf876be881c46231f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The value is useful for QPA plugins built in repos other than qtbase,
to decide if it should be a default plugin or not.
Currently useful for qtwayland.
Also export a qmake value assignment when doing static builds, just
like src/gui/configure.pri does.
Change-Id: I1253f1a7e178b24b16e2615ba20d1e92b0b87b1a
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Otherwise we get error messages from CMake.
Change-Id: I374b87e38550062b841b7eacf5fbb6bb5ccbdbde
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Allow CMake for Android to use ANDROID_NDK_ROOT to deduce the path for
QT_CHAINLOAD_TOOLCHAIN_FILE instead of the user providing it manually.
Change-Id: Ida728011d5ca8d5a723d341ea77b173e8f105f8c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is meant to be called by our CI instructions to build standalone
tests of a Qt repository.
Currently it just calls qt-cmake with
-DQT_BUILD_STANDALONE_TESTS=ON, but it might contain more things in
the future.
The script also simplifies configuring standalone tests locally, due
to not having to remember the name of the magical variable.
Change our CI instructions to use the new script.
Change-Id: I6bc02b4e94adc9d0d05fecb0fe70a561043271f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
With the introduction of the new 'default_qpa_plugins' custom target,
a target dependency cycle occurred in qtwayland:
qtwaylandscanner -> default_qpa_plugins -> a wayland qpa plugin ->
WaylandClient -> qtwaylandscanner
The issue is twofold:
- default_qpa_plugins accidentally depended on non-qpa plugins.
- All qpa plugins were enabled by default, including the wayland ones.
Fix the default_qpa_plugins target not to depend on regular non-qpa
plugins.
Also fix qpa plugins not to be enabled by default, but instead only
choose one qpa plugin to be the default (via evaluating the
DEFAULT_IF) condition.
Amends df9c7456d1
Change-Id: I22cd2c72f6b75be54263fd21097258bd179e3616
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The way we detected whether SysrootifyPrefix needs to be set was
incorrect.
We checked if extprefix == prefix => SysrootifyPrefix should be
true. But that was previously always the case for a non-prefix build,
which means it was not possible to build apps (due to qmake expecting
to find include dirs in the sysroot, despite the non-prefix Qt not
being installed anywhere into the sysroot).
Instead we should do what qmake does. Only set SysrootifyPrefix to
true if extprefix was not provided and a sysroot is available.
To make it work for iOS and Android, the sysroot detection code had to
be moved earlier than the SysrootifyPrefix detection.
Task-number: QTBUG-86053
Change-Id: Idcc1260a675fb2ef9ae27fc9dc42a68b30f763b8
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The html_docs target does not need to call QDoc a third time as
both its dependencies already do that.
With qmake, html_docs did invoke QDoc if CONFIG did not include
'prepare_docs', but none of the Qt modules used that configuration.
We can manage without it for now.
Fixes: QTBUG-87751
Change-Id: I45d2d06006c566c431ae41d7f3a06d6b809987f2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
For top-level builds it's desirable to have "ninja generate_docs" build
all tools needed to generate the documentation.
This is problematic since the doc-generating targets are created before
the doc tool targets. Thus, we must defer the dependency connection if
the doc tool target is not yet available.
This patch adds the functions qt_internal_defer_dependency and
qt_internal_add_deferred_dependencies.
Change-Id: Ica940b80882e67cb0e0943e95541f7f4d1885948
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Instead of propagating the deprecation wranings, we compiled all code
with -Ddeprecations.
Change-Id: I0233ddc85bdbdcb93d366073b2cea5d47bdbe52a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
qmake treats internal modules as just the regular module file,
but with a _private suffix, as opposed to the current cmake
logic, that treats it as the private module file, resulting
in missing e.g. the Qt.foo.module entry.
Change-Id: Id55ca4c23921656d5abfd1d0fdf6430d4fe120bf
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This patch allows in top-level prefix builds to build Qt and to generate
the documentation without running cmake --install first.
For top-level builds we now always use the qdoc binary from the build
directory, not the installation directory.
We also have to copy the global doc files to the build directory to make
them accessible to the generate_docs target.
Change-Id: I2251603418fc3df9a21c7f2892789e9ff6c8cc21
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's not sufficient to pass -I{prefix}/include when doing the header
clean check.
We need to propagate all target include directories and compile
definitions, and also the compile flags for good measure.
For macOS frameworks we also need to explicitly pass an -iframework
flag (qmake passses -F instead), to ensure that <QtGui/qfoo.h> style
includes are found when building other repos than qtbase.
Task-number: QTBUG-82615
Change-Id: I76d12340bc01c5c948ff04df9a3df384dcb7e076
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This ensures ccache or sccache is used to cache the compilation of the
headerclean checks.
Task-number: QTBUG-82615
Change-Id: Ie944eb1d643e7271551c9f8337609741e419e9d8
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
It appears there's a difference between the chosen macOS compiler path
in the CI versus the compiler path on my local machine.
In the CI the chosen compiler path ends up 'being /usr/bin/clang++'
whereas for me locally it's
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
For some reason the headersclean commands succeed in the CI, but
locally they fail for me saying that standard library includes can not
be found, unless an explicit sysroot flag is specified.
I assume that in the CI the '/usr/bin/clang++' compiler shim chooses some
implcit sysroot, whereas the longer Xcode compiler expects an explicit
sysroot.
It's probably also affected by the fact that in the CI we pass an
explicit CMAKE_OSX_SYSROOT to a non-standard Xcode location e.g.
/Applications/Xcode11.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
Note the '11' in the Xcode app name.
Locally I don't pass a custom CMAKE_OSX_SYSROOT, and my Xcode is
installed in a regular location e.g /Applications/Xcode.app.
The sysroot flag and path is added to regular CXX compilation rules
inside CMake's core (in cmLocalGenerator.cxx).
Reuse the same variables that CMake uses and add them to our headersclean
command rules.
Task-number: QTBUG-82615
Change-Id: Ic03ea27e39471f5fa168eb5970bf3d3f1d1be251
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Add 3 new convenience custom targets:
'qt_plugins', 'qpa_plugins' and 'qpa_default_plugins'.
Additionally, if we detect that an internal executable / test
links against Gui, add a dependency on the 'qpa_default_plugins'
custom target, so that if a developer configures Qt for the first time
and then calls ninja 'tst_foo_check', we ensure the test will launch
successfully because the default QPA plugin will also be built.
Change-Id: If6dd70844b5effdf8a293f65f8785855cc85b132
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For example, we must not prepend -l to -pthread, -framework and -lfoo.
Fixes: QTBUG-87760
Change-Id: Ie1bc7a76183c2c4980c519b5f23dde6c47ec85a9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...instead of qt-cmake-private.
Also, add ".bat" on Windows.
Change-Id: I2aa94ac76f2dadfb8e94d68b19bb379b3d45a93d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The variable to check for a Windows host system was mis-typed.
Change-Id: I25b14b80d25bfec0c1a00e99833520b6fb6a4b02
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
This makes the diff-ing of the config summary between qmake and CMake
builds correct.
Change-Id: I720b69572c23afd78e6d0bea6cdf0740980c3b36
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
In configure.json files we have inputs with dashes, e.g.
bundlex-xcb-xinput. In configure.cmake files, these are read in their
normalized form, e.g. INPUT_bundled_xcb_xinput.
Normalize the input names in QtProcessConfigureArgs.cmake like we
already do for feature names.
Change-Id: Iece414d40a0e9e2920580f2fda68e25cd32674c9
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
...for QT_BUILD_TOOLS_WHEN_CROSSCOMPILING.
qt_internal_export_additional_targets_file now gets two lists of target
names when run from qt_export_tools:
- TARGETS containing actually existing targets, and
- TARGET_EXPORT_NAMES containing the target names as they appear in the
additional target info file.
Operations that require actual targets are run on the TARGETS, in the
additional target info file only TARGET_EXPORT_NAMES are written.
This distinction is required for the case where the host Qt lacks a
tool that is built in the target Qt.
Example: host Qt is built with DEVELOPER_BUILD=OFF, target Qt is built
with DEVELOPER_BUILD=ON. Then the host Qt lacks qmljs, but it is built
in the target Qt. TARGETS contains qmljs_native, and
TARGET_EXPORT_NAMES contains qmljs.
Fixes: QTBUG-87693
Change-Id: I615aed996bfcbe654274defcda8c1cb2cc4b7b4e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Do not append "/qtbase" to QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX
when doing a top-level build. The "/qtbase" suffix is already part of
this variable's content.
Fixes: QTBUG-87682
Change-Id: If1c2075dc58d4b07a4c3a1eed12cc3336c5dc8e6
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Do not print warnings for the configure arguments -commercial,
-opensource and -confirm-license. We're not removing the arguments yet
to keep existing build scripts working.
Fixes: QTBUG-86096
Change-Id: Ieb63e2f2b81c022e8559cde6c3e0be0b8ce655ca
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The use-case is relevant for other platforms as well.
Now that Qt has a module system we can also replace a lot of the
hand crafted logic for linking with simpler constructs.
Change-Id: Ib6853aaf81bfea79c31f2de741d65b4b56f23ef6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Some of them have a different (hopefully better) name now.
Some are marked as Technical Preview.
Some are renamed to be internal.
Marking add_qt_gui_executable as TP with the intention to un-TP it
after we rename it and change its behavior as discussed in the API
review meeting.
Additional changes to add_qt_gui_executable and qt6_add_resources have
been filed as separate tasks that will be worked on separately.
See comments on PS1 for details.
Task-number: QTBUG-86827
Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
We want this in order to be able to export constexpr members.
Change-Id: I33ba7964ebee54fe656df983985d8d6fa0b99358
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This needs to map to ECM_ENABLE_SANITIZERS.
Fixes: QTBUG-87316
Change-Id: I9e983728af0ba69fd428944e647f0afae8c61772
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Provide two customization points:
- optionally include a 'qt.toolchain.extra.cmake' file if it exists
and is placed next to the main generated toolchain file.
This use case is mostly for the Qt installer, so that it can create
an extra file with correct installer-provided paths, instead of
patching the toolchain file directly.
- optionally include a file passed via the command line CMake argument
'QT_TOOLCHAIN_INCLUDE_FILE'.
The use case is for application developers that might want to adjust
the toolchain file after the modifications done by the Qt installer.
These options do not replace the existing QT_CHAINLOAD_TOOLCHAIN_FILE
option, which is meant to chainload a platform specific existing
toolchain file (like Android or Emscripten).
Task-number: QTBUG-87068
Change-Id: I956949840f55742cfbd3bc8fc0bd8c6b3f774d3d
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
And wrap the various behaviors into separate functions.
Change-Id: If940351af34e445de050f2b46301de7080b1555b
Reviewed-by: Cristian Adam <cristian.adam@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>
It appears that CMake's Xcode generator default behavior can't really
handle imported object libraries location, which Qt uses extensively
(all the qt_add_resource calls).
Specifically the project fails to configure with the following error
message:
The OBJECT library type may not be used for IMPORTED libraries under
Xcode with multiple architectures.
An issue was filed upstream at
https://gitlab.kitware.com/cmake/cmake/-/issues/21276
In the mean time, it looks like it's possible to work around the issue
by setting XCODE_EMIT_EFFECTIVE_PLATFORM_NAME global property to OFF.
This needs to be done before the very first project() call, so we do
it in the generated Qt toolchain file.
Note that the workaround only works if the CMake project is configured
with a single architecture given to CMAKE_OSX_ARCHITECTURES.
If multiple arches are given, it will fail with the same error
message.
Fixes: QTBUG-87198
Change-Id: I2556ae28b2fc2d9cfe464a5acf9c4fcbaf01b654
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add info whether Qt was an infix built, and whether the reduce_exports
feature was enabled. These variable were set before in
Qt5CoreConfigExtras.cmake.
Change-Id: Id077763cfffd5ee6f1a7a28d04cf92dc46390c54
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Add an abstraction over Qt::WinMain (aka qtmain.lib) and
iOS's runtime linker entry point (_qt_main_wrapper).
The Core target will now link against the Startup target on all
platforms, instead of just WinMain on Windows.
The creation and linkage interface definition of the Startup target
is done at find_package(Qt6Core) time via the private call of
_qt_internal_setup_startup_target().
This will add automatic linkage of WinMain to executables marked with
the WIN32_EXECUTABLE property on Windows.
As well as the addition of the '-Wl,-e,_qt_main_wrapper' linker flag
when linking iOS executables.
Qt users can opt out of this behavior by either setting the
QT_NO_LINK_QTMAIN property or variable. This is in line with
Qt 5 behavior.
Task-number: QTBUG-87060
Change-Id: I7d5e9f1be0e402cf8e67e6f55bfd285f9e6b04f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
As there is no other way of obtaining information about Qt's paths at the
moment, windeployqt is still querying qmake for these information. For a
cross compiled Qt, the proper target mkspec has to be set in this case.
Change-Id: I0b7b7719c9055d432576185ac4f7572a5ba1dd6b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When loading the tool packages from the host Qt we must ignore
QT_NO_CREATE_TARGETS. Otherwise tool targets like Qt6::moc are not
available.
Task-number: QTBUG-85080
Change-Id: I2c8c8e68863f28a4f1d9cd2f70090455c49d8df2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Tests were never built by default, except for -developer-build.
Examples were build, but aren't anymore by default if you
run cmake directly.
Let the default be figured out by cmake, and only set
BUILD_EXAMPLES and BUILD_TESTING if the user has
expicitly passed them via -make or -nomake.
Task-number: QTBUG-87217
Change-Id: I37321d96cc1e9e184a711a858c860b0205d5b74f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
3.17.0 is released since a while. ANyhow, the requirement for
3.17 for simulator_and_device builds is already mentioned
at the start.
Change-Id: Ic8813bb60b010feb97a47b878124c3e75658813d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
All usages should be replaced with qt_internal_add_executable instead.
This should fix configuration failure of benchmarks and manual tests.
Amends e0c62a48b8
Task-number: QTBUG-86815
Change-Id: I0791d849998ed9517e32f699d843367949b97cb9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This variable can be set when using qt-cmake[-private] to override the
CMake toolchain file that is chainloaded by Qt's toolchain file.
Task-number: QTBUG-87068
Change-Id: Id529408381e4174becda1ba07a489535c8cf1314
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
These were introduced in
675805e9eb and
b9c85d6b0e
They should be exported if they were set.
Change-Id: Ieec565980ba148f675f84dcdd7c19894e349085f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The value is used by mkspecs/features/mac/default_post.prf and
ultimately by xcodebuild to decide which arch and SDK to build
against.
For a simulator_and_device build, no value needs to be set as far as
I can see.
Task-number: QTBUG-87218
Change-Id: I41992bec6b16aadfd87c3f7c10653a6094e76d3e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If no mkspec is provided, we default to the macx-clang-ios mkspec when
building for iOS. This ensures that the wrapper qmake script is usable
for building iOS apps with qmake.
Task-number: QTBUG-87218
Change-Id: Ib02b580c8382b04455c9f820163062591d14a15b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Introduce a new feature called 'FEATURE_msvc_obj_debug_info' which
should allow usage of sccache for Windows MSVC configs.
Enabling the feature will replace the default '/Zi' compile flag
that CMake sets in Windows-MSVC.cmake with '/Z7'.
This ensures that the debug info is placed into the compiled object
file instead of placing it in the compilation .pdb file via
mspdbsrv.exe.
The final pdb file will still be created for shared libraries and
executables due to the linker '/debug' flag.
Static libraries will not have a .pdb file, instead the debug info
being embeeded in the .lib file.
The downsides of using '/Z7' are more disk space usage, slower
link times, more memory used for linking because the linker needs
to deal with more symbols.
The upside is that caching each indepedent cl.exe call is possible.
This is what Chromium uses with goma, and Firefox with sccache.
We're not enabling the feature by default to allow easier
testing (and switching it off) in the CI if it proves not to be
feasible.
It will probably have to be disabled at least for building
qtwebengine due to high memory requirements.
Task-number: QTQAINFRA-3934
Change-Id: I89e0e57995e938a780be318d1faec700194aa93f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Enabling it will force usage of '-O3' flag when building Qt.
If the platform has no '-O3' flag, use '-O2' as a fallback.
Task-number: QTBUG-86866
Change-Id: If13f7de954ba5c01dc9634f06a85529828fe90a9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Introduce a bunch of helper functions to manipulate compiler
flags and linker flags for the
CMAKE_<LANG>_FLAGS_<CONFIG>
and
CMAKE_<LINK_TYPE>_LINKER_FLAGS_<CONFIG>
CMake variables.
These variables can be assigned and modified either in the cache
or for a specific subdirectory scope, which will apply the flags
only to targets in that scope.
Add qt_internal_add_optimize_full_flags() function which mimics
qmake's CONFIG += optimize_full behavior.
Calling it will force usage of the '-O3' optimization flag on supported
platforms (falling back '-O2' where not supported).
Use the function for the Core and Gui subdirectories, to enable full
optimization for the respective Qt modules as it is done in the qmake
projects.
To ensure that the global qmake-like compiler flags are assigned
eveywhere,
qt_internal_set_up_config_optimizations_like_in_qmake() needs
to be called after Qt global features like optimize_size and
optimize_full are available.
This means that qtbase and its standalone tests need some special
handling in regards to when to call that function.
Task-number: QTBUG-86866
Change-Id: Ic7ac23de0265561cb06a0ba55089b6c0d3347441
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Supports installing linker generated debug info for shared libraries
and executables, as well as compiler generated debug info for static
libraries.
Works with Ninja Multi-Config as well, with the caveat that the files
are installed optionally, aka the install rule will not error out if
a pdb file is not present. This is necessary, because it's not
possible to create per-config install rules properly.
Fixes: QTBUG-87006
Change-Id: I95e91a6557eb0ee0f882103be54cd38795c349f7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Implement the last remaining Android-related configure options for the
CMake build.
Print warnings for options that have no equivalent in the CMake build.
Let -android-ndk automatically deduce the CMake toolchain file, and
error out if that fails with a hint how to fix the situation.
Task-number: QTBUG-85373
Change-Id: I8399e5334ae0f1f6634e381775a308d34f7c482b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qtConfAddWarning was missing, despite being used.
All of the three qtConfAdd* functions take multiple parameters and pass
them to the CMake's message() function.
Change-Id: I1fad46c6fd00b2e733b32cda482bbf1341ffc63f
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>
Add some missing versionless functions.
Rename some functions that are not meant to be public API, and their
usages.
Task-number: QTBUG-86827
Change-Id: Ifb66c04cd7598d83fe80c01a92ab2d269ebaf396
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The CMake build uses the WARNINGS_ARE_ERRORS variable, and the feature
warnings_are_errors exists only in the qmake build.
Change-Id: I1e548b30b210b3dd1b2f23041d490a981312f4ba
Reviewed-by: Cristian Adam <cristian.adam@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>
Add qt6_android_get_sdk_build_tools_revision() function to get the
Android SDK build tools revision, the logic is moved from
QtPlatformAndroid to Qt6AndroidMacros. The update QtPlatformAndroid
header comments.
Task-number: QTBUG-85982
Change-Id: If3e5b46fa583f929a24794792c9d5a52beb83990
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make name format of QT_ANDROID_DEPLOYMENT_SETTINGS_FILE consistent with
qmake, that is android-${target}-deployment-settings.json.
Task-number: QTCREATORBUG-24678
Change-Id: I2bdb056cf7a82fd83aaf658f3a405a0c9ef05756
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This ensures that we have the configuration-independent IMPORTED_*
properties set on tools.
Fixes: QTBUG-86893
Change-Id: I2b772c21341e6e4631379d4a5a99580ec96909ed
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To provide the IMPORTED_LOCATION target property we must write
the *AdditionalTargetInfo.cmake file for all debug-only builds, not only
the ones containing a release configuration.
Task-number: QTBUG-86893
Change-Id: I9ecd01483660f434a3f1ea12fa2af756cdcf9932
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It causes issues in our Windows CI, because the strawberry perl
pkg-config is found. And even that one is unusable, due to a bug in
CMake which is tracked at
https://gitlab.kitware.com/cmake/cmake/-/issues/21239
Change-Id: I58816195d35459e8a44c923399c35a4956c222a2
Reviewed-by: Simon Hausmann <hausmann@gmail.com>
By default, when using the Qt6 CMake package to look for components,
the find_package() calls for the components use NO_DEFAULT_PATH to
ensure that CMake doesn't accidentally find system (distro) packages.
Instead we limit the paths to one level up from where the Qt6 package
is.
Unfortunately that doesn't quite work for finding Qt packages that
might have been installed into a different prefix than where the main
Qt prefix is.
This happens when Qt addons are built by Conan, and installed into
a separate prefix.
To allow calls like find_package(Qt6 COMPONENTS ConanAddon) to work
in a scenario as described above, introduce a new variable called
QT_ADDITIONAL_PACKAGES_PREFIX_PATH which can be used to specify
additional paths where Qt CMake packages should be found.
This is similar to previously introduced QT_EXAMPLES_CMAKE_PREFIX_PATH
variable which was meant for a similar case, but only for examples.
Additionally, allow disabling the NO_DEFAULT_PATH option by setting
the QT_DISABLE_NO_DEFAULT_PATH_IN_QT_PACKAGES cache variable to TRUE.
This would allow regular usage of CMAKE_PREFIX_PATH to work, at the
risk that system Qt CMake packages might be found.
Augments 5cd4001bf2
and ffe0889413.
Fixes: QTBUG-86882
Change-Id: Ia8e060cbba6d2a10c3d63d81892f2c71e4236a9a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Make the use of ANDROID_SDK_ROOT consistent.
Task-number: QTCREATORBUG-24678
Change-Id: If967bdc4d252996098fa210cf38429fe075eacb1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To support finding Qt headers of modules installed into a different
prefix than the main one, add the $import_prefix/include path as a
public include path for each built Qt module. With this, includes like
#include <QtNetworkAuth/QOAuth2AuthorizationCodeFlow> will work.
The macOS framework case is handled automagically by CMake, which
ends up passing '-iframework $import_prefix/lib'.
Change-Id: I02ce9cacf157aab9721c1d6073a377607c5b89c7
Fixes: QTBUG-86881
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Building a user project in Release configuration against a Qt built with
CMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug led to the user project
being linked against the Debug Qt libraries. This is especially painful
with MSVC where debug and release runtimes are incompatible.
We now create *AdditionalTargetInfo.cmake files along the
exported *Targets.cmake files that set the IMPORT_*_<CONFIG> properties
to the values of the release config Qt was built with.
User projects built with an unknown
configuration (CMAKE_BUILD_TYPE=ArbitraryName) will link against a
release Qt. This can be controlled by setting the variable
QT_DEFAULT_IMPORT_CONFIGURATION to, for example, DEBUG in the user
project.
Fixes: QTBUG-86743
Change-Id: I12c4b065a9845c7317f6acddab46b649f2732c9e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Consider a Qt module with a 3rdparty library target in
PRIVATE_MODULE_INTERFACE, e.g. XKB::XKB in Qt6::GuiPrivate. Consumers of
GuiPrivate automatically depend on XKB::XKB. In order to do that they
must find_package(XKB ...). As all find_package calls for GuiPrivate are
in the same place as the ones for Gui, this package must be marked as
optional. Otherwise all consumers of Qt6::Gui would have to have the
xkbcommon package installed too.
This patch exports find_package calls for every 3rdparty public
dependency of private modules and marks them as optional.
Change-Id: Ia1eeb09c29927fb6634ef08b477684ed6f123267
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Apparently the combination of the --no-undefined linker flag together
with ASAN when building on Linux with Clang does not work.
Disable --no-undefined flag in such a scenario. Note that linux-clang
mkspec doesn't add that flag at all, which is why asan builds work
there.
Change-Id: I6167c757ce4be5d2263311bc84e5fb445b0f7c2d
Fixes: QTBUG-86879
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Rename all libQt6*.so to libQt6*<infix>.so
Task-number: QTBUG-85438
Change-Id: I4b91ffaaec7bea61454b0d3c794c77f2d0868d54
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
00a1e5da7e wrongfully added parts of
QtPlatformAndroid.cmake which were removed in
32121e9882. This removed the part in
question again
Change-Id: Ie18968e6a165f52c68f4941ced6add266985bc48
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
All system frameworks use 'A' instead of the major version of the
framework, and Xcode's code signing assumes that the framework version
is 'A' when signing embedded frameworks (FB7323980), so leave the
version 'A'. This is also what Apple recommends.
Change-Id: Idbf2e30e156c3e869da8f75731e568524d9407e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Offer compatibility wrapper functions until we update all of the Qt
repos to use the new names.
Task-number: QTBUG-86815
Change-Id: I5826a4116f52a8509db32601ef7c200f9bd331de
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
When re-doing in a top-level build, we did not read the config.opt file
from the top-level directory.
Also, the config.opt file should not contain the -top-level argument.
This is an internal option, and on Windows, it was already missing. The
information whether we're doing a top-level build is now passed in the
CMake variable TOP_LEVEL.
Change-Id: Iaecd7306a4b6d9ad494684c201cf12f8e74d684b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Having ${QT_BUILD_DIR}/include as include path is not enough for
modules outside of qtbase. They also need to pick up headers from e.g.
Qt Core, which are available only in "${CMAKE_INSTALL_PREFIX}/include"
This amends db21bad936
Fixes: QTBUG-82615
Change-Id: Ib003a66ce039bf1ab6e21a3b1cd86923207eb3db
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We must use the LIBRT location instead of LIBRT_FOUND which is not set anywhere.
I failed to replace this one in my previous patch.
Change-Id: I6e2df82c31e29018d99afec1eecfb80a321fddd4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt_add_test supports now QT_TEST_SERVER_LIST, which will add the test
servers as docker test fixtures.
The docker server will be started before the test is run, and stopped
after the test is run.
Running the tests in parallel is not supported.
Docker tests are currently only supported on Linux hosts.
Task-number: QTBUG-85034
Change-Id: If3cefe05c5dec19c14b05d2fa8b01a0b6d95e259
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Avoids a linking error when the library is not found as
find_library sets GLESv2_LIBRARY to GLESv2-NOTFOUND
Change-Id: I7ddc15483276e0be0c78b67b760c4d9188758270
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
If a consumer wants to cross-compile a Qt app, they need to provide
the host Qt path location.
When building Qt in the CI we embed the Qt host path into the
generated CMake toolchain file for convenient building of other Qt
modules.
But once Qt is built, packaged and installed on a user's machine, most
likely the Qt host path will not be the same. In such a case, if the
user wants to use the convenience toolchain, they should explicitly
provide the Qt host path via the QT_HOST_PATH and
QT_HOST_PATH_CMAKE_DIR variables.
Show an error message if the values are not provided or don't exist
on the file system.
It's possible that in the future the Qt installer will patch the
toolchain file, or provide additional info, to point to the host
Qt installation so that the user doesn't have to do it manually.
But until that's done, a friendly error message is a good way to
inform the user what they should do.
Task-number: QTBUG-83999
Change-Id: I26291e3c47bb77375f8a5ce7b848c0382a660ca9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Public consumers of the qt toolchain file will most likely not have
their compilers in the same location where they were on the Qt build
machine.
Only set the compiler paths if none was set already, and the paths
actually exist.
This seems to become a trend in the generated toolchain file, and is
only a stop-gap solution.
A proper solution (two different toolchain files) may follow.
Task-number: QTBUG-83999
Change-Id: I7a603af447333a45c65b98e299ee109932d16517
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
A previous change accidentally broke what we we set for
QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR.
The QT_HOST_PATH variable should use an absolute path as it was
done before.
The QT_HOST_PATH_CMAKE_DIR variable incorrectly used the value of
"${QT_HOST_PATH}" instead of "${QT_HOST_PATH_CMAKE_DIR}".
Fix both of these, and change the names of intermediate variables
to be consistent.
Amends a6a3b82ffb
Task-number: QTBUG-85240
Change-Id: I328a7edee12a13ff793684e8a0a4c2e03204eca4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This reverts commit b0c51f86f4.
The build failure caused by 58c1c6ee5c has
been fixed.
Change-Id: Ic7458d54c7a874588e8b1bfeca61df1842763656
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This reverts commit 6e1a570dc8.
The build failure caused by 58c1c6ee5c has
been fixed.
Change-Id: I67acaa2d1dd5fc88c205b054252be2e6e26898c7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...and fix the build errors the original change caused.
This reverts commit 127fb8bb55.
Change-Id: I4006b32734a51c5d101dd73c957f81d2a0f84ba1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This reverts commit 58c1c6ee5c.
This lead to configuration errors on some machines, blocking
development.
Change-Id: I744f6cc95fbaa273519ab8fc8fb492b87f5729b8
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This reverts commit a3cb002511.
This lead to configuration errors on some machines, blocking
development.
Change-Id: Ibb785c96c7d85692a6e22a73e086119eb571df71
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This reverts commit 3685483c4b.
This lead to configuration errors on some machines, blocking
development.
Change-Id: I309cdd55a8ef64899afcbeca54458d1c6d686951
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Every public dependency of a Qt module results in a find_package call in
the consuming project. But not all public dependencies are mandatory.
For example, vulkan is only needed if the user project actually uses Qt
classes that pull in vulkan headers.
This patch adds the option MARK_OPTIONAL to qt_find_package.
Dependencies that are marked as optional will not produce an error on
find failure.
Task-number: QTBUG-86421
Change-Id: Ia767e7f36991e236582c7509cbd37ea3487bb695
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...in code. The actual number of calls at runtime does not change.
The reason for this stunt is that we want to replace find_dependency
with find_package at runtime for optional dependencies, and this will
reduce the diff size of the next commit.
Change-Id: I304fdf09c69fea7b6d4adabf515712eb097f8c86
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The find_dependency() macro calls return() on failure, meaning any code
after it will be ignored, thus checking any XXX_FOUND variables after
find_dependency() is pointless.
Fix the places where we use find_dependency() and set the "failed" state
before the call and the "success" state afterwards.
Change-Id: Ia5239c704f02a9bec972210374ffed7808b14055
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is needed for qtwayland, where QtWaylandCompositor package should
call find_package(QtWaylandScanner) in the 'Tools' section of the
ModuleDependencies.cmake file, rather than the regular 'Qt' section.
This takes care of handling host path prefixes, to ensure that a host
package is found even when tools have also been cross-compiled via the
QT_BUILD_TOOLS_WHEN_CROSSCOMPILING option.
Task-number: QTBUG-83968
Change-Id: I4725a630214d053105fb6d2a0f7c5ff6128d13f9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
qt_apply_rpaths takes into account properties like MACOSX_BUNDLE. This
property might not yet be set when qt_internal_add_app is called, but
later.
To handle that, move the call of qt_apply_rpaths to
qt_internal_finalize_app.
As a result, the installed apps will have 2 rpaths, the $ORIGIN style
relocatable one, and an absolute path one pointing to the Qt
prefix/lib. The last one might be unnecessary.
Fixes: QTBUG-86514
Change-Id: I25e0d695c78c8b5703e94c99cc2457f772721456
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
win32-clang-g++/qmake.conf did define
QMAKE_CFLAGS_WARN_ON += -Wextra -Wno-ignored-attributes
probably for the same reason.
Change-Id: I14b66f2555949c03a2ea996923e31f5ec9f7105a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Some repos/modules don't have configure.json files and thus no
qt_cmdline.cmake files. Make qt-configure-module check for the file's
existence. As drive-by fix, surround the configure.cmake's path by
double quotes.
Change-Id: If1a91a0bba0c2fd282cfa08fa6ff2bb20f0a15ba
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
For modules that have MODULE_INCLUDE_NAME set (for example ActiveQt) we
must use this name for the installation rules too.
Fixes: QTBUG-86484
Change-Id: I1b97cf534ea5e41655c7b3fdd0330b2f58356a3a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This configure switch sets the CMake variable
CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG> per release config to ON.
The feature 'ltcg' is enabled if any of the variables
CMAKE_INTERPROCEDURAL_OPTIMIZATION,
CMAKE_INTERPROCEDURAL_OPTIMIZATION_<CONFIG> are ON.
In order to implement the check, configurejson2cmake had to be extended
to be able to write extra CMake code before and after the feature
definition. This extra code can be added to a feature mapping below the
keys "cmakePrelude" and "cmakeEpilogue".
Task-number: QTBUG-85373
Change-Id: Ia2eb907edcf087f137977a9b090705397f83eb05
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Add a convenience script to configure a Qt module separately.
This script reads and interprets the qt_cmdline.cmake files of the
Qt module to be configured and eventually calls qt-cmake-private.
Example usage:
<install-prefix>/bin/qt-configure-module <source-root>/qtdeclarative
-qml-network -- --trace-expand --trace-redirect=cmake.trace
Change-Id: I026f1a050cd3f4df740611c32ba8c03161bba7a3
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Make this file parsable by tools that are less lenient than github.
Triple-backquotes are for fenced code blocks. Inline code uses backticks
(or double backticks if you have code with backticks).
Change-Id: Ic49d946fbcaa6f7e97702eadf4a0b0c726fc3217
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If '-make examples -no-compile-examples' was specified, sources of Qt's
examples would be installed, but the examples would not be built.
This switch has always been a source for confusion and is only
interesting for distributors, who can just package the examples
directory tree.
Change-Id: I0291d70e4951d98b553a4abf217db49d05316d3a
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The include directive was incorrectly written.
This amends 5c092c2b40.
Change-Id: Ia72ca3a5d5e1486ade4d71a764550d36979640f6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We need to use the imported host tracegen target to generate files, not
the one we're going to cross-build.
This amends 5c092c2b40.
Change-Id: Ib74dd2d87110383c31216872eb55bebf5d90df37
Reviewed-by: Samuli Piippo <samuli.piippo@qt.io>
qt_record_extra_package_dependency is called by qtwayland to register a
dependency between the qtwaylandscanner tool and the waylandscanner
tool.
When cross-compiling the tools in a Yocto environment, the adjusted
target name was not taken into account.
Task-number: QTBUG-83968
Change-Id: Ibf7b94876bf29827cf0d9c9bb471f359ef6ff15f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This works around linking issues when doing yocto non-prefix Qt
builds, because CMake does not add -rpath-link flags even though it
probably should.
Task-number: QTBUG-86533
Change-Id: Iaaf246ac71ca05d9369ceb6eb9c4a1e206c42839
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
I accidentally noticed the message in a CI job, but it didn't fail the
build because the FATAL_ERRO was considered as another text token to
print, instead of a command keyword.
Change-Id: I0e30ebacbed32d1017f9ded681cd6b15cbc32573
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The qt_build_internals_disable_pkg_config_if_needed function didn't
actually check if the pkg-config executable is available when turning
the pkg-config feature on.
This broke certain configurations like Android (on some hosts).
Try to find the executable and take that into account when computing
the value of the feature.
Task-number: QTBUG-85399
Change-Id: Ie79c637f2d2b689c392862c90075d309906fe506
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The generated toolchain file embedded windows style paths for the
android sdk and chainloaded toolchain. This caused CMake does fail at
configure time while trying to evaluate backslashes as escape chars.
Also syncqt was searched for in libexec, which is not the right
directory on Windows. Use the host info package to get the location of
the 'libexec'.
Task-number: QTBUG-85399
Task-number: QTBUG-85911
Task-number: QTBUG-86053
Change-Id: I1b15ce84496d52c3fda2f65138e1eac43bc95c9e
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Rather than force setting the apple sysroot and Qt host paths, first
check if they are not already defined on the command line and if they
aren't, check that the paths with which Qt was configured exist.
The goal of the patch is to not set invalid paths, like when using a
Qt built in the CI, which will have a different host path / sysroot
compared to what a user has locally.
Task-number: QTBUG-85240
Change-Id: Ic37566b4fa845d8d1b4e4b5ba7fa4be769e99ca8
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Using find_library() to find an Xcode framework will end up embedding
the absolute path of the framework into INTERFACE_LINK_LIBRARIES.
A different machine might not have the SDK installed in the same
location, which will cause build failures. This happens in our CI
because Xcode is installed to /Applications/Xcode11.app.
To fix this, replace all system framework paths with
'-framework Foo' flags instead.
We already do this for OpenGL and OpenGL ES.
In the future we might want to convert these into full standalone
FindFoo scripts that expose proper targets.
Fixes: QTBUG-86299
Task-number: QTBUG-86422
Task-number: QTBUG-85240
Change-Id: I22b2b2d1d9e92108098d3974105e3758978cd8e2
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
We don't support older compilers from before they accepted
the architecture codenames.
Change-Id: If13a10ed95b34007858bfffd1631a08b425fa9c3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
This was added for Qt 5 in 780137d585 but
apparently the change was never ported over to CMake.
Fixes: QTBUG-86452
Change-Id: If13a10ed95b34007858bfffd1631a084370a3232
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Until now, QtProcessConfigureArgs.cmake could only handle qtbase and the
top-level build. Add the variable MODULE_ROOT that the user can point to
the module that is to be configured.
Example - QtDeclarative can now be configured like this:
cd qtdeclarative-build-dir
echo -qml-network > config.opt
cmake -DOPTFILE=config.opt -DMODULE_ROOT=<source-root>/qtdeclarative \
-DCMAKE_COMMAND=<install-prefix>/bin/qt-cmake-private \
-P <source-root>/qtbase/cmake/QtProcessConfigureArgs.cmake
A convenience script that saves the user from entering this unwieldy
incantation will be added in a subsequent commit.
Change-Id: If46103de3a8eb84b15e7600ebfec25544451e1d5
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
We never passed a valid target name to qt_apply_rpaths.
This amends fde98f7794.
Task-number: QTBUG-85399
Change-Id: I1c023ce30a3a8b5ec43d020373960d19fe20f59a
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
We need to call qt_apply_rpaths for targets that are created with
qt_internal_add_app too. This is in line with what qt_app.prf does.
Task-number: QTBUG-85399
Change-Id: If5ffb05cca191c6cae9a330e1f4556d342a68ff8
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
AndroidManifest.xml file and the Android plugin already has a way
to provide commandline-arguments to app with the tag
"android.app.arguments". This change allow to set it from qmake/cmake
and allow Qt Creator to use that.
Task-number: QTCREATORBUG-23712
Change-Id: I3e680f40fd36ba6aaac7f344fb9509d2c3360e74
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
For prefix builds we need to install the file.
Amends db21bad936.
Change-Id: Ia8e859dc048cc4bd74eb95ed0d2adce9c6b11902
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Fix name of target so that qtattributionsscanner actually generates content.
Change-Id: Ie42067928d7cd1de02fa4ae92a0f5ef54bd54a5c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Make sure the executable path contains an .exe on Windows.
Change-Id: I972a3aaf1ad0510525ebfcc84e8c589f555c6d00
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
C4180, C4458 were disabled already in 2012, in commit 6668f5becf.
C4577 was disabled due to QtScript being compiled without exception
support in commit 97d7d80e73.
Anyhow, Qt Script is now officially gone in Qt 6, and Qt headers
do work just fine with C4180. Finally, C4458 is nowadays a W4 warning,
so not enabled in the first place.
Task-number: QTBUG-82615
Change-Id: I2f9b8e858817876b069a166129fbfac7ef3587a0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
