We extend configurejson2cmake to read the "commandline"
information from configure.json. This data is then translated to CMake function
calls and written it into commandline.cmake files.
We extend QtProcessConfigureArgs.cmake to pick up those commandline.cmake
files to feed our command line handling code, which is a
re-implementation of the command line handling in qt_configure.prf.
The command line handler sets INPUT_xxx variables, similar to
configure/qmake's config.input.xxx variables. The INPUT_xxx values are
translated
- to -DFEATURE_xxx=ON/OFF arguments if the input represents a feature,
- to corresponding CMake variables if such a variable is known,
- or to -DINPUT_xxx=yyy CMake arguments.
Configure arguments that have an entry in
cmake/configure-cmake-mapping.md are actually implemented. Other
arguments are likely to need more work.
Task-number: QTBUG-85373
Change-Id: Ia96baa673fc1fb88e73ba05a1afb473aa074b37d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To fix CMake Qt For Android projects to configure, we need to move
some functions from a private CMake API file only, to a public one.
Add Qt6AndroidMacros.cmake which will be loaded by Qt6Core package.
We'll have to decide how we proceed with Qt5AndroidSupport.cmake,
because that file automatically runs code when included in Qt5, and we
usually don't want to do it.
We'll also have to decide how to handle the define_property() calls
that are still left in the private QtPlatformAndroid.cmake file.
With this fix, Qt example CMake projects that use
add_qt_gui_executable should now be buildable. An APK can be created
with 'ninja apk'.
Unfortunately Qt Creator 4.13 does not currently seem to support
opening and building CMake Qt For Android projects properly.
While the build succeeds after fiddling with the Kit settings, the APK
deploy step fails to run (at least on my machine).
So the simplest way to run the built APK is to open the android-build
dir with Android Studio and launch the example application from there.
Task-number: QTBUG-85399
Change-Id: I77f246331de7a6e9e6d4ba7d973730190138f136
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Fix detection of qt android platform plugin by globbing inside
the install qt6 prefix location. This is just a sanity check.
Fix platform plugin detection for CMake standalone tests configured
using qt-cmake-standalone-test, which used to look into the fake
standalone prefix location instead of the real Qt location.
Fix detection of stdlib path using CMAKE_SYSROOT.
Add a global apk target that allows easier building of all apk targets
defined in the project. Creation of this target can be opted out by
setting QT_NO_GLOBAL_APK_TARGET to TRUE.
Amends b1f8ca8032.
Task-number: QTBUG-85399
Change-Id: Ic9c1646b4f00e0084fe3f4397df471b8f925afd8
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The helpers can now be included manually in a project to call any
required function. There was a use case for that in qttools, which was
not possible because including QtPostProcess early would produce side
effects.
Task-number: QTBUG-86035
Change-Id: I05d5576bbac45d4b9e298b23aa2a33088d64968e
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
QtBuild.cmake is huge. Split it.
Move module, plugin, tools, executables and test related functions out
of QtBuild.cmake into separate files.
Do the same for many other things too.
An additional requirement is that all the new Helpers files only
define functions and macros.
No global variable definitions are allowed, nor execution of commands
with side effects.
Some notes:
qt_install_qml_files is removed because it's dead code.
Some functions still need to be figured out, because they are
interspersed and depend on various global state assignments.
Task-number: QTBUG-86035
Change-Id: I21d79ff02eef923c202eb1000422888727cb0e2c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The endless saga of fighting with qt_find_package and global target
promotion. In certain scenarios we want to opt out of target promotion
to global scope.
One such case is in qttools with WrapLibClang and Threads::Threads.
Threads::Threads will be found in the top-level scope via
Qt6Dependencies.
WrapLibClang is declared in src/ directory scope, and
then we try to promote it ands its dependencies to the global scope,
via qt_find_package() ->
qt_find_package_promote_targets_to_global_scope().
This fails because we can't promote Threads::Threads due to it being
added in a different subdirectory scope.
Introduce 2 new functions.
qt_internal_should_not_promote_package_target_to_global and
qt_internal_disable_find_package_global_promotion.
The first one is used to disable promotion of targets to global scope
in qt_find_package.
To mark a target not to be promoted, the second function is used.
It will be used by qttools for the WrapLibClang case.
Task-number: QTBUG-85877
Change-Id: If6caf10a94999402026517a623ae29e3ab1eeb7f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Also use the value to actually write it into qconfig.cpp so that qmake
reports the right information.
Change-Id: Icc4bf36b0dc6ad75d93ac16f39e5b361c0ce52b4
Fixes: QTBUG-81289
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Our initial approach to looking for host Qt tools when cross-compiling
to a platform with a different architecture bitness compared to the
host one was to unset CMAKE_SIZEOF_VOID_P before calling
find_package(Qt6FooTools) and then restoring the value.
That works to bypass the architecture bitness test in the
ConfigVersion files, but it also influences the paths that
find_package() searches in, specifically the lib<arch> paths like
/usr/lib64 will not be searched in.
Fortunately since CMake 3.14, write_basic_package_version_file() can
take an additional ARCH_INDEPENDENT parameter. This disables the
architecture bitness test when looking for the package, while allowing
to still search in the /usr/lib64 like paths.
Use it when creating the QtFooToolConfigVersion.cmake files.
One could argue we should actually check if the tool executables could
run on the host system where find_package is called for
cross-compilation.
We could do that in another change if the problem ever arises.
Amends 03aa74e40d
Amends 914b367c7f
Change-Id: I1181ff637ac80064a6a8538170b28a41743fc90c
Fixes: QTBUG-81672
Reviewed-by: Christophe Giboudeaux <christophe@krop.fr>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This file provides common feature-functionality is supposed to be
included by QtFeature.cmake and QtProcessConfigureArgs.cmake.
Change-Id: Ifb483c2a9c4014d240c2a4d6ff07b5c0ceee9c3a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If the user specified CMAKE_OSX_DEPLOYMENT_TARGET=10.15 for the Qt
build then building projects with qmake failed, because the mkspec
hard-codes QMAKE_MACOSX_DEPLOYMENT_TARGET to 10.14.
We now write QMAKE_MACOSX_DEPLOYMENT_TARGET to qconfig.pri to override
the mkspecs' default.
Fixes: QTBUG-85923
Change-Id: I6a39cfe047ac0f99e1da0ca0728d63c741bd4fed
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This automatically sets the CMake Generator to be the same as the one
used for qtbase.
Change-Id: If9e1a6942520417393055c572f0d892efca43d2e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Apparently CMake encods targets from different scopes with a different
encoding scheme for earlier CMake versions.
CMake 3.16.3: Threads::Threads::@<0x5604cb3f6b50>
CMake 3.18.0: ::@(0x5604cb3f6b50);Threads::Threads;::@
Handle the earlier version approach as well. It needs to be done both
when writing out 3rd party dependencies, as well as for lib prl files.
Possibly in more places as well, but I didn't detect additional
places yet.
Amends 92ee9bd6b8
Task-number: QTBUG-85801
Task-number: QTBUG-85877
Change-Id: Ib348b51b2d623fb50d9080dba2beeb931d47a69c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
It's not immediately obvious that you need to use
all underscores for the feature name, so add a
line that explaines it.
Change-Id: I508eaf909c808fb0a93442f6e71428c18559b965
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We expose it in the private QtBuildInternals package, but we need it
also as public information for consumption in qt_import_qml_plugins()
to decide whether it should do anything.
Change-Id: If135ae596b4edaf8e2c458f6a2518b968c6d01c4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
For qt_import_qml_plugins to work, it needs to have access to the Qml
plugin targets by the time find_package(Qt6Qml) is called.
To do that, we modify the generation of Qml plugin Config, Targets and
Dependencies files to go into a special 'QmlPlugins' subfolder of the
Qml package.
The Qml package will then GLOB include all the Config files in that
folder, to make them available whenever find_package(Qt6Qml) is
called.
This is similar to how the Qt plugins were glob included in the CMake
integration of Qt 5.15. In fact that glob including is missing in Qt 6
for regular Qt plugins, and should be implemented in a following
change. Currently the Qt Plugins config files that are included are
hardcoded to the list of known plugins at Qt configuration time.
As a drive-by to make this all work, the naming of the various Config
and Dependencies files has been normalized to include the Qt6 prefix.
This is done for both regular Qt plugins and Qml plugins.
Task-number: QTBUG-85961
Change-Id: Id20da72337ca2945fa330ea6fb43535e44a83292
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Embed package versions into the qt_find_package calls for various
Linux specific packages.
Task-number: QTBUG-82917
Change-Id: I5d1cb623f81932dfae4658b8a3a89eedb71ea3af
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If certain 3rd party libraries have a version that's not suitable for
Qt, the configure summary should say so, rather than use them and fail
at build time.
With the current situation, we have to duplicate the version
information from the configure.json files in helper.py, by assigning
the version number as an extra find_package variable.
Rerunning configurejson2cmake then embeds this version info into the
qt_find_package calls in configure.cmake.
Some of the Find modules are rewritten to take the specified version
into account when looking for the libraries.
This involves moving around the code for creating a target, after
calling find_package_handle_standard_args() so we know if a good
enough version was found.
Task-number: QTBUG-82917
Change-Id: I139748d8090e0630cda413362760034dc3483e11
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Before clang 9, it was enabled by default
when -fsanitize=undefined was set.
Pick-to: 5.15
Change-Id: I0faf3ae1901d4badc6d265fa8081185be4360636
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Most of the time lld just gets stuck (deadlock) waiting on some
mutex, thus failing integrations.
Amends 64c111e10f
Task-number: QTBUG-85911
Change-Id: Id73bf967a7aeb0e0cbccfaafe056b325c8711f82
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Static Qt plugins should not be included in the list of libraries of
a prl file. They end up being there due to our circular dependency
trick where the plugins depend on the module they belong
to.
This in turn causes the giant static plugin generator expressions to
be processed in qt_collect_libs(), and the generated prl file ends up
having target names like Qt6::QJpegPlugin which are obviously not
linker flags.
To eliminate the static plugins from prl files, add an additional
dummy boolean generator expression '$<BOOL:QT_IS_PLUGIN_GENEX>'
that always evaluates to true. We can string match on this expression
in qt_collect_libs, and thus remove the whole static plugin genex
entry.
This should fix linking of apps with qmake that use a CMake-built
static Qt.
Task-number: QTBUG-85865
Task-number: QTBUG-85240
Task-number: QTBUG-85801
Change-Id: I949dc5edb10d94c4ab84ed430af7c164d8efaaa6
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
mkspecs/features/qt.prf adds a dependency on the system threading
library if the Qt Core thread feature is enabled. Because qt.prf is
loaded by any public or internal Qt project, it's essentially a public
dependency for any Qt consumer.
To mimic that in CMake, we check if the thread feature is enabled, and
and set the Threads::Threads library as a dependency of Qt6::Platform,
which is a public target used by all Qt modules and plugins and Qt
consumers.
We also need to create a Qt6Dependencies.cmake file so we
find_package(Threads) every time find_package(Qt6) is called.
For the .prl files to be usable, we have to filter out some
CMake implementation specific directory separator tokens
'CMAKE_DIRECTORY_ID_SEP' aka '::@', which are added because we call
target_link_libraries() with a target created in a different scope
(I think).
As a result of this change, we shouldn't have to hardcode
Threads::Threads in other projects, because it's now a global public
dependency.
Task-number: QTBUG-85801
Task-number: QTBUG-85877
Change-Id: Ib5d662c43b28e63f7da49d3bd77d0ad751220b31
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The include directory in Qt's build directory is always named
"include", no matter what the value of INSTALL_INCLUDEDIR is. The main
reason is that the name "include" is hard-coded in syncqt.
The INSTALL_INCLUDEDIR variable must only affect the installation
location of headers.
Fixes: QTBUG-85893
Change-Id: I5367bc589cba129eb41817e2b58d470f730bb5ac
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The logic is a bit involved in qmake.
The Qt internal qt_common.prf adds CONFIG += strict_c++ which applies
to qt modules, qt plugins, qml plugins, qt helper libs, winmain and
qt_apps, qt_tools, but NOT tests (which is important because the tests
on Windows MinGW fail to build without the GNU extensions).
Then default_post.prf checks for the strict_c++ value and either uses
the strict or non-strict C++ standard flags. default_post.prf is
loaded for all qmake projects, not just the Qt internal ones.
Now CMake doesn't provide a transitive based option to disable C++
GNU extensions with a mechanism similar to target_compile_features.
It only provides the CXX_EXTENSIONS property and it's associated
CMAKE_CXX_EXTENSIONS variable. We can't set the variable at a
directory scope, because that is too coarse grained.
So we rely on setting the property via a function in every relevant
qt_add_<target> function.
Now the naming of the function is weird.
We name the function as qt_internal_<...>, because it's not meant to be
used by Qt users.
We prepend an underscore to the name because we need to place it in
Qt6CoreMacros, so that the function can be called by
qt_add_qml_module which IS a public function.
That's because in Qt5 load(qml_plugin) was private API, but in Qt 6 +
CMake we decided to make qt_add_qml_module() as public API.
Change-Id: Id014626b087d590e25cb46843f93d0c67fc36e44
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Windows shared library prl files should not have a
QMAKE_PRL_LIBS section. Such information is not useful because it's
not used by the linker as per 523c7e3fd5
Amends 46d7abc9172f82756ccd3641a314dcc066353c3f
Task-number: QTBUG-85240
Task-number: QTBUG-85801
Change-Id: Ic40491a568f72c507a16322f6f0c61f98d3a5913
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This adds the option to build Qt with libb2, which is especially
recommended, if you care about the performance of the BLAKE2 hashing
algorithms. The bundled version is the pure reference C implementation
of BLAKE2, while libb2 has many additional hardware optimizations.
However, the API of both is the same, so no changes to the code were
necessary here.
Change-Id: I3563982f4e07be300291fe103c38b16a404b3ebb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Apply the same kind of transformations to the contents of the prl
files as we do for pri files. Mainly, transform system library paths
that are absolute, into link flags to make them relocatable across
systems.
Also change the Qt frameworks to be linked via the -framework flags
instead of via absolute paths.
Implementation notes
Move the common required functions for both QtFinishPrlFile and
QtGenerateLibPri into a common QtGenerateLibHelpers.cmake file.
Make sure it's listed as a dependency for the custom commands.
Also make sure to pass the necessary input values like possible
library prefixes and suffixes, as well as the link flag.
Task-number: QTBUG-85240
Task-number: QTBUG-85801
Change-Id: I36f24207f92a1d2ed3ed2d81bb96e4e62d927b6e
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This new function is meant to be used where load(qt_app) is used.
It delegates functionality to qt_add_executable, while handling
some additional behavior via a finalization function (mostly handling
of macOS Info.plist files and icons, as well as Windows icons and
resource files)
It uses a new PlatformAppInternal interface target.
Task-number: QTBUG-85757
Change-Id: I1a2d5851b137fcd4a6323e0e06fb154f91619800
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Our CMake build system only generated working .prl files for
the Release configuration in debug_and_release.
This caused a linking failure when building a Widgets example that
links against qtmain, specifically
qtmaind.lib(qtmain_win.cpp.obj) : error LNK2019: unresolved external
symbol __imp_CommandLineToArgvW referenced in function WinMain
The symbol is located in shell32.dll, which was not linked in, because
there was no qtmaind.prl file.
The fix to generate per config prl files is a bit complicated, because
add_custom_command does not support generator expressions in OUTPUT
and DEPENDS.
Instead we pre-generate 2 files per config, one with the preliminary
prl file content and another file that contains the final prl file
path (via generator expression).
Then we iterate over all configurations and create custom commands
with well known paths, and the final prl file is created by the script
called by the command.
Amends 06557312d2
Task-number: QTBUG-85240
Change-Id: I413b705bc69732b0cbe1ee8cd089a1aef19365db
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
On Windows, if Qt is built with Vulkan support but the user's machine
does not have Vulkan, it should still be possible to configure and
build an application (if the application does not use Vulkan of
course).
When Qt is built with qmake, the special windows_vulkan_sdk.prf file
makes sure not to export build time Vulkan include headers into the
generated .pri files. The same file also tries to find the include
headers via an environment variable. If it isn't set, it just adds a
bogus "/include" include path, which doesn't fail a user's application
build.
This wasn't the case for an application built with CMake, because the
exported Vulkan_nolink target uncodinitionally referenced Vulkan's
target properties. Which means that if the Vulkan package was not
found, the application failed to configure.
To mimic qmake's behavior, make sure to query the target properties
only if the Vulkan target exists, via the TARGET_EXISTS generator
expression.
Apply the same logic to all _nolink targets. This might not be
entirely correct in all cases, but we can revise this behavior later
after more feedback. At the very least it allows building non-Vulkan
based applications.
Task-number: QTBUG-85240
Change-Id: Iffbb03a84e8637ed54d0811433e66fe6de43d71f
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This fixes the macOS build when you only have the CommandLineTools installed.
Change-Id: I620bc535b508b604a875f53dec8c57af23efeac1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
While trying to implement the 'host artifact reuse' Coin instructions
change, a bug surfaced where the qemu configurations didn't find
the host tools and instead tried to use the cross-compiled tools
while building qtbase, which failed due to not finding the
runtime linker (another unsolved issue).
Before the host artifact reuse change, the host tools were found
successfully.
The difference that caused the issue is that the target install prefix
was a direct subfolder of the host prefix.
host - /home/qt/work/qt/install
target - /home/qt/work/qt/install/target
Before the host reuse change the install prefixes were as follows
host - /home/qt/work/qt/install/host
target - /home/qt/work/qt/install/target
While looking for the Qt6CoreTools package, we temporarily set
CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH to contain first
'/home/qt/work/qt/install' and then '/home/qt/work/qt/install/target'.
CMake then reroots the CMAKE_PREFIX_PATH values onto values in
CMAKE_FIND_ROOT_PATH, making an MxN list of prefixes to search.
Rerooting essentially means concatenating 2 paths, unless the
considered prefix is a subfolder of the root path.
What happened was that the first considered value was
'/home/qt/work/qt/install/home/qt/work/qt/install', a non-existent
location that gets discarded.
The second considered value was '/home/qt/work/qt/install/target.
The second value is the result of seeing that
'/home/qt/work/qt/install/target' is a subfolder of
'/home/qt/work/qt/install' and thus the root path is stripped.
All of this is done in cmFindPackageCommand::FindConfig() ->
cmFindCommon::RerootPaths.
The behavior above caused the target tools be found instead of the
host ones.
Before the host reuse change, both of the initial constructed prefixes
were discared due to them not existing, e.g.
'/home/qt/work/qt/install/target/home/qt/work/qt/install/target'
and '/home/qt/work/qt/install/host/home/qt/work/qt/install/host'
One of the later prefixes combined CMAKE_FIND_ROOT_PATH ==
'/home/qt/work/qt/install/host' + CMAKE_PREFIX_PATH == '/' resulting
in '/home/qt/work/qt/install/host/' and this accidentally found the
host tools package.
We actually stumbled upon this issue a while ago when implementing Qt
5.14 Android CMake support in 52c799ed44
That commit message mentions the fix is to add a "lib/cmake"
suffix to the PATHS option of find_package().
This would cause the subfolder => strip root behavior mentioned
above.
So finally the fix.
First, make sure not to append QT_HOST_PATH in the toolchain file,
there shouldn't be any need to do that, give that we temporarily set
it when looking for Tools packages.
Second, recreate the subdir scenario in the Qt toolchain file by
setting CMAKE_FIND_ROOT_PATH to the current (relocated) install
prefix as usual, but also setting CMAKE_PREFIX_PATH to a new value
poining to the CMake directory.
Aka '/home/alex/qt' and '/home/alex/qt/lib/cmake'.
Third, when a QT_HOST_PATH is given, save 2 paths in the generated Qt
toolchain: QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR. There are the host
equivalents of the target ones above. Use these values when looking
for host tools in Qt6CoreModuleDependencies.cmake, again facilitaing
the subdir behavior.
Note these are currently absolute paths and are not relocatable.
We'll have to figure out if it's even possible to make the host path
relocatable.
Finally as a cleanup, look for the Qt6HostInfo package in QtSetup
strictly in the given QT_HOST_PATH, so CMake doesn't accidentally find
a system Qt package.
Change-Id: Iefbcfbbcedd35f1c33417ab7e9f44eaf35ff6337
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
gcc doesn't report warnings for final methods since version 9.2:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010
Change-Id: I7152351aac0e3bad86d777e119f25137ef97ec6f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Change added dep in qt_add_cmake_library():
PlarformModuleInternal -> PlatformCommonInternal.
Change-Id: I303a6a520f0dda7260b12cb21673b8f1a23d536b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It doesn't understand the arguments we usually pass to testlib.
Change-Id: Iea83d1d8c31a510b2bc442cbfc810eac631322e7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Sometimes the info we show in the configure summary might differ from
the information that CMake computes.
To more easily debug and fix such cases, print out various CMake info
variables like host and target info, compiler versions, sdk versions,
etc.
Change-Id: I37a11dfabe5369236af78684a09bd3cec3fdd398
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
There was an inconsistency where configuring qtbase on Apple Silicon
with the following command line produced different results rom the
second variant.
$ cmake ../qtbase -DCMAKE_OSX_ARCHITECTURES=arm64
vs
$ CMAKE_OSX_ARCHITECTURES=arm64 cmake ../qtbase
That happened because the CMAKE_OSX_ARCHITECTURES variables was not
passed to project-based try_compile calls. This resulted in compile
tests like SIMD avx to succeeded on Apple silicon, which shouldn't.
To address that, always pass the architecture on macOS if it's
specified.
Change-Id: Ia12e86230cc6e5e11f387e3cbb273d90646ef2e3
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Qt6 package was not found the tests were configured in-tree as opposed
to standalone tests.
Use the same trick we do for building examples in-tree.
Specify the path to the build tree packages, and don't create targets.
Amends 96e3ee0659
Change-Id: Ia60de416ce0afff5bd40be8c0c6e3c7898fd7ebf
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This change provides the following per-module variables
Qt6Widgets_LIBRARIES, Qt6Widgets_INCLUDE_DIRS, Qt6Widgets_DEFINITIONS,
Qt6Widgets_COMPILE_DEFINITIONS, Qt6Widgets_PRIVATE_INCLUDE_DIRS.
These are deprecated and are only intended for easier porting from
Qt5 to Qt6. Qt consumers should instead rely on the Qt module targets
e.g target_link_libraries(app PRIVATE Qt6::Widgets)
Note that the variable contents includes transitive values for
everything except the _LIBRARIES variant. So Qt6Widgets_INCLUDE_DIRS
will contain values for Widgets, Gui and Core.
Qt6Widgets_LIBRARIES only contains a value like Qt6::Widgets, and when
that is used in target_link_libraries(), CMake will take care of the
transitivity.
Change-Id: I625e25aab7ba5eaf14de1dc76ba2a1a0c85e6226
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Each module package needs to first find the Qt6 package to ensure
that all the necessary info is setup for further depedencies to be
found.
Task-number: QTBUG-81672
Change-Id: I3ee608d24c1efbb63a063261fb36341bf52fb78d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This makes sure the executable is run as a shell script
with the proper interpreter on Unix systems.
Otherwise it will fail in some shells, like fish.
On windows, it prevents all commands in the batch file
from displaying on the screen.
Change-Id: If554262f172b035b9661b3e2ff26a96789fa707b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For repositories other than qtbase the QT_STAGING_PREFIX was empty,
because it was only determined in qtbase.
Also, we save the CMAKE_STAGING_PREFIX in the Qt6BuildInternals package
and set this variable if it's not explicitly set by the user.
As with CMAKE_INSTALL_PREFIX this behavior can be prevented by defining
QT_BUILD_INTERNALS_NO_FORCE_SET_STAGING_PREFIX=ON.
Change-Id: I73100abbef24f5d3fb8f82029d0374176edc8048
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The prefix value must be surrounded by double quotes in case it
contains whitespace.
Change-Id: I393c57368d7a255f5042e363405071ef042afc18
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Fix the conditions in qt_add_simd_part for arch_haswell and the
avx512 profiles to mimic what simd.prf does.
Add missing SIMD flags in QtCompilerOptimization for arch_haswell.
Compute the compile flags for the avx512 profiles from the
profile dependencies.
Remove the special case in Gui that hardcoded the compilation of
qdrawhelper_avx2.cpp to be conditional on avx2 being enabled
instead of arch_haswell. The Gui project already has another
qt_add_simd_part that is enabled if arch_haswell is enabled, which
will now work correctly due to the fixes in qt_add_simd_part.
Change-Id: I7a61a03b5565d4fa438f22b329e0d9dd7acd9273
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Certain resources and compiled jar files have to be copied into the
non-prefix build dir location. They were previously only installed,
which doesn't do anything in a non-prefix build.
Change pro2cmake to generate code that places the compiled java
jars into QT_BUILD_DIR, so that non-prefix builds work.
Place the module dependencies xml files into lib folder in non-prefix
builds.
Don't special case the output and install location of the Android QPA
plugin.
Task-number: QTBUG-85399
Change-Id: I4ac9d3929ea8ecc95ec99a77e621ad2121b68832
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qdevice.pri should embed info about the Android SDK, NDK, host,
platform api level and ABI.
The machine tuple test should not be run for uikit and Android
platforms.
Sysroot should also not be prepended for uikit and Android
platforms, otherwise it breaks Qt module include paths.
Task-number: QTBUG-85399
Task-number: QTBUG-82581
Change-Id: Ic48c88f6ab15d75c2ebc323c8d7a3b7e5596f3c1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The path was wrong if CMAKE_STAGING_PREFIX was set.
Change-Id: Iec90c7a5edf0da80a0ac108fe3411c340c01e9a9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The qt-cmake-standalone-test script is kind of a "host tool" and
contained paths to CMAKE_INSTALL_PREFIX, which is wrong if
CMAKE_STAGING_PREFIX points to somewhere else.
Fixes: QTBUG-85336
Change-Id: I4828dc6868d55cfc60f3ad2199185230d5cc9028
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the cache variable QT_STAGING_PREFIX that is the same as
CMAKE_STAGING_PREFIX - if it's set, or CMAKE_INSTALL_PREFIX otherwise.
Use the variable in the places where we check for the emptiness of
CMAKE_STAGING_PREFIX to use CMAKE_INSTALL_PREFIX.
Change-Id: I372d57dfa41818c1965b824c59ab3cac80b38f60
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This add support for the following options: -debug, -release,
-debug-and-release. For the latter, the "Ninja Multi-Config" generator
is auto-detected, if ninja is available.
Task-number: QTBUG-85373
Change-Id: Ide0ca44e5f4c74657147e89d71e8d71c4f6a4c45
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Remove the -cmake-makefiles configure argument as its meaning was in
essence "do not pass a -G argument to CMake".
Instead, we add the following arguments:
-cmake-generator <name> to pass -G <name> to CMake
-cmake-use-default-generator to pass no -G argument to CMake
If none of those arguments is given, we try to autodetect the
generator. If a ninja executable is found, we prefer the Ninja
generator. On Unix we fall back to "Unix Makefiles".
On Windows, we do a poor man's compiler detection and select one of
"NMake Makefiles", "NMake Makefiles JOM" and "MinGW Makefiles".
Change-Id: Ic36669bd50956d15fbc71cee73720732cd4bfab8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The configure scripts need to translate configure options to CMake
arguments. It is not sensible to implement this translation twice, in
sh and Windows batch language, so we're doing this once, in CMake
language.
The configure scripts write their options into config.opt and call a
CMake script that reads config.opt, does the translation to CMake
arguments and calls CMake to generate the build system.
While we're at it, implement some more translations than the sh
configure provided, like -extprefix, -top-level and -skip.
Fixes: QTBUG-85349
Fixes: QTBUG-85350
Task-number: QTBUG-85373
Change-Id: Ida5d8b2a3c178b9349d41ec76d190c69a9456e74
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Interface libraries like our Qt header modules should not propagated
private defines which are meant only for building a specific Qt
module, and in the case of a header module there is nothing to build.
Exclude the usual private defines we set in qt_add_module for header
modules. This also fixes the content of header module .pri files.
Change-Id: I0791ebdb73e8b020ddb8116433ed36c7b3d71303
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QT_WILL_INSTALL was set to ON, because an incorrect comparison was
done.
Amends 062318feb2
Change-Id: I201aa2a183563ce05077c36ac2ba3bd61cc827c0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
To achieve this, we save the result of the subarch test in the cache
variable TEST_subarch_result and use this value as the right hand side
of the QT_CPU_FEATURES.xxx assignment. The Qt6HostInfo package now
sets the variable QT6_HOST_INFO_SUBARCHS which will be used for the
host_build scope in qmodule.pri when cross-building.
Change-Id: I2c25f205bfc0692aef0d6f43ff4e542d27e1b948
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Apple deprecated the entire OpenGL API in favor of Metal, which
we are aware of, so we don't need to see the warnings when building
Qt.
Instead of applying the silencing globally for all Qt consumers,
both internal and external, we now limit the silencing to Qt itself.
That means user code that explicitly uses any of the deprecated APIs
will see the warnings. Note that this does not apply to merely using
any of the Qt OpenGL APIs. The user has to explicitly use the platform
APIs that have been deprecated.
The warnings need to be disabled on a build system level, so that
that they are passed as -D flags on the command line. If the defines
were done in Qt headers (qguiglobal.h e.g.), they would require the
user to always include this header before any of the Apple headers.
Change-Id: I3f2a2a5211332a059ad4416394251772c677fdcb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Add internal documentation how to map configure options to CMake
arguments. This patch adds a markdown file with a giant table, and
cmake/README.md links to it.
Change-Id: I94a6a4ee24ed0114ccb3095d2c13cf5d84e2de72
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It wasn't possible to create a cross, non-prefix build with
CMAKE_INSTALL_PREFIX set to something else but the qtbase build dir
and CMAKE_STAGING_PREFIX set to the qtbase build dir.
This would be equivalent to
configure -prefix /usr \
-extprefix ~/my/qtbase/build/dir
Fix this by comparing the qtbase build dir against
CMAKE_STAGING_PREFIX if it is set. We also have to adjust the
QT_BUILD_DIR variable in a similar way.
Change-Id: Iaba5cf0f6954ae4b15d8af1fc62634f5d7f68835
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This patch modifies the two preprocessor definitions
QT_CONFIGURE_HOSTBINDIR_TO_HOSTPREFIX_PATH and
QT_CONFIGURE_HOSTBINDIR_TO_EXTPREFIX_PATH which are exclusively used
by qmake (and not QtCore's QLibraryInfo) to determine the ext prefix
and the host prefix.
In the qmake build of Qt, qmake considers the host prefix as "location
where qmake is installed". This is usually the same as the ext prefix
but can be modified by the user at configure time.
In the CMake build, we don't build tools for the host but always for
the target platform. The QT_HOST_PATH is an external prefix we never
install to. That means, the qmake we build is always installed into
the ext prefix (CMAKE_STAGING_PREFIX or CMAKE_INSTALL_PREFIX).
Therefore, we can calculate the path of <ext_prefix>/bin relative to
<ext_prefix> and use this value for both,
QT_CONFIGURE_HOSTBINDIR_TO_HOSTPREFIX_PATH and
QT_CONFIGURE_HOSTBINDIR_TO_EXTPREFIX_PATH.
The "path of <ext_prefix>/bin relative to <ext_prefix>" is equivalent to
just the "path <prefix>/bin relative to <prefix>", meaning we can
safely use <prefix>, which is just CMAKE_INSTALL_PREFIX.
Task-number: QTBUG-84886
Change-Id: Ie1d4628a7049ddfd0d0a56dfe4ee2f2bb4952277
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Building an iOS app with qmake failed because Qt itself was not built
with bitcode enabled.
Enable building with bitcode.
Make sure qrc resource files and bundled 3rd party libraries also
build with the regular Qt module flags and thus with bitcode enabled.
As a consequence gc_sections has to be disabled for UIKIT platforms.
Task-number: QTBUG-82581
Task-number: QTBUG-84781
Task-number: QTBUG-85240
Change-Id: I15fe668725a139c02f2a32a5db849b46d4ce325c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This is required for qmake to correctly pick up and use plugins that
have strange characters in the types (slashes for platforms/darwin
type and dashes for wayland plugin types).
This fixes some issues with trying to build an iOS application
using qmake due to the qiosnsphotolibrarysupport plugin.
Task-number: QTBUG-85240
Task-number: QTBUG-84781
Task-number: QTBUG-82581
Change-Id: I94faf2d3dbbdeb22dbd96dfb11c7bff00645b524
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The EffectivePaths section does not inherit the Prefix value from
the Paths section.
Specfiy it explicitly, otherwise the paths reported by qmake -query
for /get variants ended up containing an extra "./bin/" part, which
ended up breaking building iOS apps with qmake.
Amends d7fd684861
Task-number: QTBUG-85240
Task-number: QTBUG-84781
Task-number: QTBUG-82581
Change-Id: I288a6e76a21d779a7e03443777f8a4ce28df9974
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
target_link_libraries expects a quoted string like
"-framework CoreFoundation" when linking frameworks and not 2
different arguments like "-framework" "CoreFoundation".
Fix that in the FindWrapOpenGL and FindGLESv2 find modules.
Make sure to not quote the framework link flags when generating
.pri files even if there are spaces, otherwise building apps
with qmake fails.
Amends 7fcc9cf055
Amends 2ed63e587e
Amends 55a15a1c1b
Amends 2a767ab4bb
Task-number: QTBUG-85240
Change-Id: I66ba36760ad704d65e712072a528d9e25c336dfa
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Promotes qt_find_package()'d targets and their transitive dependency
targets to global scope. This will allow .prl file generation to
access targets in a sibling repo scope.
Retrofits qt_collect_libs() to be a bit more general, so it can be
reused both for prl lib collection, and traversing of dependencies
of qt_find_package() provided targets.
Removes the bail out checks for top-level static builds.
Amends 8c8c0f65e3
Amends dde11715d3
Task-number: QTBUG-84874
Fixes: QTBUG-84917
Change-Id: Id95b4cb7a0887c52f35c40bfdb96ad4a68dd6794
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Show a status message when we run syncqt for a module (gives a bit
more insight into why the configuration seems to stall for a moment).
Remove some uninformative messages about generating config.h files
and Depends headers, etc.
Change-Id: I5ff2774b9cf5d92ddde564dc09f4197c2835ee4a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qmake builds of Qt don't use libraries in /usr/local because the
path is not considered a system path. Only the SDK path should be
used as a source of system libraries.
We should do the same for the CMake builds, which involves a couple of
things.
Tell CMake not to consider /usr/local (and a bunch of other
paths) as system prefix paths.
Disable pkg-config usage which by default is not used in qmake
Windows and macOS builds.
If a user wishes to use libraries located in /usr/local on macOS, they
can explicitly enable the behavior via -DFEATURE_pkg_config=ON.
In addition to enabling pkg-config, that will also disable the system
prefix modification described above.
Implementation notes
To disable pkg-config usage, we set an empty path for
PKG_CONFIG_EXECUTABLE, because there is no other good way. The
downside to this is that a lot of warning messages will be printed
that the pkg-config package can not be found.
The pkg-config feature needs to be computed in QtBuildInternals before
qtbase/src/configure.cmake, because it's too late to do it in that
file where a few qt_find_package calls already exist.
The feature value is also saved to QtBuildInternalsExtra, to make sure
that pkg-config is disabled whenever building another repo.
System prefix adjustment is done by removing paths from
CMAKE_SYSTEM_PREFIX_PATH.
Ideally we would remove also /usr as a path, to match what qmake does,
but that breaks find_program() calls for perl, python, etc.
We have to make sure that qt_find_package does not look in
PATH when looking for packages, which is the default behavior, because
PATH on macOS most likely contains /usr/local.
One last curiosity for future generations is that CMake 3.18+ has
merged a change to prioritise SDK locations over regular /usr/lib.
Fixes: QTBUG-85261
Change-Id: I28fe5bae7997507a83b37b4eb1e0188e64062c57
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This adds the CMake equivalent to the classical -device-option key=value
configure argument:
-DQT_QMAKE_DEVICE_OPTIONS=key1=value1[;keyN=valueN]
The keys and values get dumped verbatim into qdevice.pri.
This patch also ports the machineTuple configure test. Its result is
written into qdevice.pri as value for the GCC_MACHINE_DUMP variable.
Change-Id: I29f2323fd87639fafaed99ec7446c7ee75504705
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's now possible to pass -DQT_QMAKE_TARGET_MKSPEC=foo to cmake. If the
value is not passed, then we will guess the mkspec like we did before.
Change-Id: If6e8324654cb8bd83d3cba9eb6ee1e4ad2692a2c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For a cross-built, gcc-built Qt, the qmake build writes code into
qconfig.pri that adds the --sysroot flag to compiler and linker flags.
Follow suit in the CMake build.
To keep the diff small between the qmake-generated and CMake-generated
qconfig.pri files, the sysroot code is added at the top of
qconfig.pri, which is the reason for the new 'content' string variable.
Change-Id: I50649100e4368be64bf98ca19e46312e3ebf619d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When cross-compiling, we now create a target_qt.conf file that's to be
used with the host Qt's qmake. With "qmake -qtconf .../target_qt.conf"
projects can be cross-built against the cross-built Qt.
We also create wrapper scripts for the host qmake to save the user from
passing the -qtconf argument.
Fixes: QTBUG-82581
Change-Id: Ib5866e7e820369efea9eb3171e3e3e3ca5c0c3c1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The plugin-manifests feature has the "negative" CONFIG value
"no_plugin_manifest". On negation, we're supposed to strip off the
leading "no_" instead of adding another one.
Change-Id: Id2c66da41f22881272d5b923f12b85d9fcc2c9d0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This reduces the amount of warning messages when the pkg-config
feature is disabled.
Task-number: QTBUG-85276
Change-Id: I11a6dfb6273a1e48c47d1ef5c1a5f70ba990fbc0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Before this change, the qt_lib_foo_private .pri files contained
absolute paths to libraries, e.g.
/usr/lib/x86_64-linux-gnu/libcups.so
Whereas the qmake build instead embeds link flags like -lcups.
Detect absolute library file paths, and transform them into link
flags. This should make the .pri files relocatable.
Fix the add_custom_commands to have the scripts as dependencies.
Make sure to pass the suffix, prefix and other options to the
qconfig.pri generation command as well.
Also reverse the order of the link flags, to mirror the order
that qmake generates for .pri files.
Task-number: QTBUG-84781
Task-number: QTBUG-85240
Change-Id: I7bc3b234d9c86c785b169b11f3042450aa225c1f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This is consistent with the qmake mkspec in common/mac.conf
Task-number: QTBUG-85240
Task-number: QTBUG-84781
Change-Id: I99df365a3be541356482d29eda806020f4e298d9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Our .prl files embedded an absolute path to the OpenGL.tbd file. This
obviously breaks their usage when used on another machine when no SDK
exists.
To fix that we need to use a "-framework OpenGL" linker flag instead
of linking against the absolute path library.
To convince CMake to do that, we have to create a wrapping
OpenGL target which sets an appropriate INTERFACE_LINK_LIBRARIES
property.
So create a FindWrapOpenGL find module to do that on darwin platforms.
Adjust helper.py and our build system to use it.
This tangentially amends 38cd18384f
because it recreates the FindWrapOpenGL module, but for a different
purpose.
Task-number: QTBUG-85240
Task-number: QTBUG-84781
Change-Id: I3498c19157ae31db5099e6edfb9d71490187f1d3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In a prefix build, this function uses install(PROGRAMS) which correctly
sets the executable bit. In a non-prefix build, we did file(COPY)
without explicitly setting executable permissions.
Now, we're also setting the executable bit for
qt_copy_or_install(PROGRAMS) calls in non-prefix builds.
Change-Id: I283e9aeed2a23016ee196d83d584a7eaaa5edd66
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This package is supposed to be loaded when cross-building Qt from the
host Qt installation prefix. It provides information about the host Qt
by setting various variables. The information reflects what "qmake
-query" of the host Qt would return.
All provided variable names begin with "QT6_HOST_INFO_".
Change-Id: Id568923a318d6e3b48c450663519a3727f615a8f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This gets rid of a few warnings during configuration.
Task-number: QTBUG-85276
Change-Id: I07d2fdfd8d3f81f1d780528ee6350e1a3ded9523
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
A developer could write 'ninja host_tools' to build the qtbase tools
and their dependencies, and then configure another cross-compiling
build dir pointing to the previous host build. This shortens the
workflow for cross-building when working in qtbase.
Change-Id: I69e70d23ce9df8669bcadf326d0586f097e5cb21
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Rather than embedding the full absolute path to the framework, we
should instead write a -framework Foo flag.
qmake seems to do this by specifying QMAKE_LIBS_FOO in the mkspec.
We'll try to get away with just deriving the name of the framework
from the path, to avoid having to introduce a mkspec equivalent
mapping for CMake.
This doesn't currently handle framework include paths, which qmake
also handled by harcoding QMAKE_INCDIR_FOO in the mkspec, and then
sysrootifying it via mkspecs/common/mac/sdk.prf.
Hopefully that's not really needed, given that -framework flag
should imply include paths as well.
Somewhat partially amends c254254c55
Task-number: QTBUG-85240
Task-number: QTBUG-84781
Change-Id: I70ea5021422d7b1f5afa9c4a595d1a9b8a8217d3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We can't rely on the MACOS define as that's set by our private
QtPlatformSupport.cmake that's not shipped.
Change-Id: I86c578a282a0833408a06d923954510a3579bdaa
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
