This configure switch controls the feature 'optimize_size'.
This isn't merely a mapping to CMAKE_BUILD_TYPE=MinSizeRel, because
we potentially want to combine -optimize-size with -force-debug-info,
which maps to CMAKE_BUILD_CONFIG=RelWithDebInfo.
Task-number: QTBUG-85373
Change-Id: I1a9343ebc54816f52e90e9d33ea3df4c99b1ec9f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Command line options like -debug result in setting the variable
INPUT_debug. INPUT_debug is mapped to the CMake argument
-DCMAKE_BUILD_TYPE=Debug. INPUT_debug also matches the feature
'debug', and the CMake argument -DFEATURE_debug=ON was passed.
Do not pass -DFEATURE_xxx CMake arguments for inputs that are already
handled.
Change-Id: If096dff1c6dd694545c6f671f5f3512a43c3ec50
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The -host prefix was added to the 'preliminary' directory rather than
the actual wrapper shell script. This caused it to be overwritten
every time by the cross-compiled qmake binary.
Change-Id: I103811c6aa9181fa701e3e7ecaf828ecdd1e3c90
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
On QNX the feature detection of GLESv2 is failing due to missing
symbols which are part of EGL library.
Add EGL library as a dependency if it's found on the system.
This allows OpenGL ES feature detection to work on QNX.
Task-number: QTBUG-83202
Change-Id: I90531d925fadce5d893ea9244793fc02a4595ed1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This commit allows building Qt6's QtBase using QNX 7.1 and a toolchain
file which is almost identical to what CMake has in its documentation:
https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compiling-for-qnx
set(CMAKE_SYSTEM_NAME QNX)
set(arch gcc_ntoarmv7le)
set(CMAKE_C_COMPILER qcc)
set(CMAKE_C_COMPILER_TARGET ${arch})
set(CMAKE_CXX_COMPILER q++)
set(CMAKE_CXX_COMPILER_TARGET ${arch})
set(CMAKE_SYSROOT $ENV{QNX_TARGET})
The only difference is the usage of q++ instead of QCC, which is no
longer present in QNX 7.1 SDK.
Task-number: QTBUG-83202
Change-Id: I51031540721275f2ee83cee9e7df4994a65db0e2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
On QNX 7.1 x86drm.h is located under <...>/usr/include/libdrm, unlike
linux where it's present under /usr/include.
find_path would not find it on QNX, and instead get /usr/include from
host, which resulted in a failure to compile.
Task-number: QTBUG-83202
Change-Id: I03d6c2d4dfbe91bb70df0a322e84890bd7c8548a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In qmake it's done for all qmake projects, in CMake we lean on the
safe side and apply it to building Qt itself. User CMake projects can
then choose to add it themselves.
Task-number: QTBUG-85992
Change-Id: I51919f947d43ffd9925e3d2837dcad17e480367d
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There are inconsistencies in the default optimization flags added by
CMake across configurations like Release and RelWithDebInfo.
In particular Release uses -O3, whereas RelWithDebInfo uses -O2,
as well as usage of /INCREMENTAL in release configs with MSVC, etc.
To make sure that the Qt 6 binaries built with CMake are consistent
across configs, as well as consistent with the flags we used when
building Qt 5 with qmake, add a horrible search and replace mechanism
to replaces the CMake flags with what our mkspecs indicate to use.
Ideally this would be done by providing custom CMake toolchain files
for each platform we support, and we might revisit that later if the
need really arises.
To implement the replacing, we first need the flags that should be
added. Port the QMAKE_CFLAGS_OPTIMIZE variables to CMake, which is
done in QtCompilerOptimization.cmake.
Then a new function called
qt_internal_set_up_config_optimizations_like_in_qmake will look for
any kind of optimization flags set in the
CMAKE_<LANG>_FLAGS_<CONFIG> style variables, remove them, and add
the appropriate flags that qmake mkspecs provide.
On some platforms (like Windows MSVC) the function also alters the
linker CMAKE_${TYPE}_LINKER_FLAGS_<CONFIG> style variables.
The mechanism allows opting out of this replacing by
setting the QT_USE_DEFAULT_CMAKE_OPTIMIZATION_FLAGS value.
It also allows opting into removal of flags for custom configs by
providing QT_ADDITIONAL_OPTIMIZATION_FLAG_CONFIGS. It's only removal,
because we wouldn't know what kind of config it is, and thus what
flags to add.
The currently modified configs are: Release, RelWithDebInfo,
MinSizeRel, Debug aka the usual default CMake provided ones.
The mechanism is only applied to C-like languages.
ASM is not handled to be on the safe side due to not knowing what kind
of compiler flags the platform assembler might take.
It's also important to skip RC on MSVC platforms.
Task-number: QTBUG-85992
Change-Id: I3712d5cd5a34fceab54f56a6fa46b4e678952362
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The CMake configure process fails without include guards for these
two find modules on QNX.
Task-number: QTBUG-83202
Change-Id: I3cc589f98bc3b6b22c401421927ee6dab2663fb7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QNX doesn't come with pkg-config support.
Task-number: QTBUG-83202
Change-Id: I2ac0c014a071b83ef9a2d8114bae0e9ff9b3b422
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The configure argument -qreal <type> maps to the CMake argument
-DQT_COORD_TYPE=<type>.
Fixes: QTBUG-83325
Change-Id: I94970f31ccfb241b1dd4f1d9b6cef25d6684dc05
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Introduce new CMake variables and map
-D to QT_EXTRA_DEFINES,
-I to QT_EXTRA_INCLUDEPATHS,
-L to QT_EXTRA_LIBDIRS,
and -F to QT_EXTRA_FRAMEWORKPATHS.
Those variables only affect the Qt build, not user projects.
Fixes: QTBUG-85878
Change-Id: I229df2eed1505a2619068d0d32975962b052569a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
Otherwise the Objective-C++ sources will be built with the default
compiler visibility (visible), and then linked with moc-generated
C++ sources that have the Qt overridden hidden visibility, resulting
in linker warnings such as:
ld: warning: direct access in function 'X' from file 'moc_foo.cpp.o'
to global weak symbol 'Y' from file 'bar.mm.o' means the weak symbol
cannot be overridden at runtime. This was likely caused by different
translation units being compiled with different visibility setting
Change-Id: I22e15e7e181a74de8c0a22c73d06e600e582d7fd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
First of all cmake and qmake used a different standard.
Secondly, the qmake logic enforced lvl 23 (if it was installed which
is the case on the failing machine). When this is combined with
f71a400bf6 which requires lvl 28 API to build, the android build fails to compile.
cmake logic was even worse as it enforced lvl 21 API to be used if installed.
This change requires pick to 5.15 as f71a400bf6 was picked as well.
Pick-to: 5.15
Change-Id: I89a7193b711b8bf927d02907343a49d6f27082ce
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
This is required for qttools, where the configure.cmake file lives in
the top-level source dir, but the module is in src/global.
The new CONFIGURE_FILE_PATH option allows specifying a different
location for the configure.cmake instead of the default value.
Change-Id: I260d7c93dd49337ebe07ae4cc871394da9e9c2c6
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The qml app was crashing when used by qtdeclarative auto tests. It
complained about unregistered QML types. qmltyperegistrar didn't
create registration info for these types. moc didn't output class info
about these types because the build system didn't provide the proper
include paths.
In qmake land, moc was given 2 sets of paths when building a module:
the non-installed framework dirs as -F flags, and also the
$repo_build_dir/include paths as regular -I flags.
In CMake land we only gave include paths to the non-installed
framework dirs as -I flags, not -F flags.
That's because AUTOMOC checks for a specific pattern in the include
paths to transform them into framework include paths
(existence of Foo.Framework/Headers symlink),
and we didn't pass such an include path.
Make sure to mimic what qmake does, and pass -I flags to
$repo_build_dir/include as public include paths, but only via
BUILD_INTERFACE aka when building Qt itself.
Also pass -F flags by specifying framework include paths in the
pattern that AUTOMOC expects.
Fixes the following qtdeclarative tests
tst_qdebugmessageservice
tst_qqmlinspector
tst_qqmlenginedebuginspectorintegration
tst_qqmlpreview
Task-number: QTBUG-84886
Change-Id: Iab9693d9889bf6d2c40fed067ab9b9da8683a053
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
* Assume UTF-8 on all Unix like systems
* Export some functions to be able to compile QTextCodec once
moved to Qt5Compat.
Task-number: QTBUG-75665
Change-Id: I52ec47a848bc0ba72e9c7689668b1bcc5d736c29
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
We must filter out expressions of the form $<TARGET_PROPERTY:name>, because
1. They cannot be used in file(GENERATE) content.
2. They refer to the consuming target we have no access to here.
The CMake error
Error evaluating generator expression:
$<TARGET_PROPERTY:QT_PLUGIN_CLASS_NAME>
was triggered when building the UiPlugin module of qttools.
Change-Id: Idf639be50120b94d68a70965604e6f1ef72edc9b
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Embedding the initial CMAKE_CXX_COMPILER into qt.toolchain.cmake
breaks Boot2Qt builds, because the CXX environment variable is not
used anymore when building qtsvg or other projects.
Disable automatic embedding when cross-compiling, while keeping it
enabled for non-cross-compiling cases (to keep Windows and
and ICC configurations working).
Allow opting in or out of the embedding in case if the default is
wrong, via QT_EMBED_TOOLCHAIN_COMPILER.
Task-number: QTBUG-85067
Change-Id: I1d8f9f580bc379b77c34eefb5728bb49f93cc81a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Assuage the fears in the previous commit, by actually querying and
using the public defines set on a target, rather than hardcoding one
single QT_FOO_LIB define + the extra namespace define.
This should future-proof .pri file generation for qmake mixing.
Amends 3452b08df6
Task-number: QTBUG-84781
Task-number: QTBUG-84881
Change-Id: Ide68ecf3f89be6d5462cfe43706c27f9cb53394f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
While we recorded the namespace define in the CMake generated Targets
file, we also have to record it in qt_lib_core.pri, so that qmake
knows to use the define when building other modules / apps.
It does scare me what other MODULE_DEFINES we might be missing, and
that we should perhaps put all public modules defines into the
generated module .pri files.
Amends 3452b08df6
Task-number: QTBUG-84781
Task-number: QTBUG-84881
Change-Id: I3175aa9991a06a4541eb0dd153ba2e6e58c019ce
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Previously .prl files were created via add_custom_command with a
POST_BUILD command. This means they were only created after linking
the libraries, and that whenever a relinking happened, dependees had
to rebuild many parts of their target.
Ideally we would use generator expressions in the OUTPUT argument, but
versions up-to CMake 3.18 don't support doing that.
A workaround is to create and depend on a .prl file name without
generator expressions, and as a side effect also create a .prl file
that does use generator expressions, but don't specify it as an
OUTPUT.
This seems to work well, and improves the dependency tracking issue,
at the cost of one more file copy per .prl file whenever it changes.
Change-Id: I7dd99777fec5a08552503bdbafb6116f93ebe66b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Use ARGN that already has the out_var parameter removed.
Change-Id: I79438caa4333a11493456fa219448ad500518880
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The referenced Qt libraries had paths to the build directory, instead
of the $$[QT_INSTALL_LIBS]/ prefix. The reason was two-fold:
1. QT_BUILD_LIBDIR had the wrong value, namely
"${QT_BUILD_DIR}/platforms/qfoo".
2. The QtFinishPrlFile.cmake script was called with a wrong OUT_FILE
parameter, placing the final .prl file in the build lib dir.
As drive-by change, surround arguments for QtFinishPrlFile.cmake that
can contain spaces with double quotes.
This amends 8c8c0f65e3.
Task-number: QTBUG-84781
Change-Id: I7188b799716576b3296ee7b2d460489867b9967a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Document what qmake expects and what CMake creates by default.
This change should fix qmake mixing for MinGW, where the WinMain
library was called qtmain.a instead of libqtmain.a.
Amends f626c73b28
and 9b0e23ef8a
Task-number: QTBUG-84781
Change-Id: I059db13f8d8a0aab8bd3fc69d4537a2b63687394
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
To make sure qmake generates appropriate rules when building other
applications.
Task-number: QTBUG-84781
Change-Id: I75618575602be820bf20a8067e3a6ee3ff7e7950
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qtremoteobjects has a tool that uses qt_process_qlalr. The function
doesn't have a check to see if the consuming target is an imported
target, to skip doing any work when corss compiling.
Fix it, like we do in qt_extend_target.
Change-Id: Ide389a371aa07225f08689d15125c04d8b0e3916
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Since commit e343affd63 we're creating object libraries for Qt
resources in static libraries. Those must be reflected in the
generated .prl files for static builds of Qt.
In qt_add_resource, we now calculate the install locations of the
object files of rcc-generated C++ files and save them in the target
property QT_RCC_OBJECTS. This property is then passed to
QtFinishPrlFile to write the object file paths to the .prl file.
Change-Id: Ic383892d723d02fc91f712bc2dbcbc90babad074
Reviewed-by: Simon Hausmann <hausmann@gmail.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We do not support building with qmake from the build directory in prefix
builds. Therefore we can just use the standard QT_INSTALL_LIBS property
instead of the /get variant.
Change-Id: I82ccaf1894fb1dccc9ec18b4984b582b555ce0f8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
A lot of qtdeclarative tests fail due to not finding the
QtTest qml plugin in ${prefix}/qml. This is just the symptom, the
problem is that the combination of CMake + MinGW + Qt relocatability
behaves incorrectly.
The value returned by
QLibraryInfo::location(QLibraryInfo::Qml2ImportsPath) for the
qmltestrunner executable is ${prefix}/bin/qml which is incorrect.
This happens due to a combination of things. The
c33916a279 change in qtbase introduced
checks to figure out whether an application is a windeployqt-ed app
to adjust the prefix path.
This check tries to find the import library libQt6Core.a in the lib
subfolder whenever the executed app dir path is equal to the
computed prefix path.
If it's found, the code assumes we are running a tool in
${prefix}/bin. If it's not found, the code assumes it's a
windeployqt'ed app, where the Qt .dlls are next to the executable.
Currently when QtCore is built with CMake targeting MinGW, we actually
create a libQt6Core.dll file instead of a Qt6Core.dll file, and also
an import library called libQt6Core.dll.a, instead of libQt6Core.a.
The prefix check code actually prepends an additional "lib", thus
trying to find the liblibQt6Core.a import library.
This fails, the code assumes a windeployqt'ed app, and returns the
currently executed app path dir as the prefix aka ${prefix}/bin in
the case of qmltestrunner, and thus none of the qml plugins are found.
To fix this, generated the shared library and the import library names
as qmake expects them, aka Qt6Core.dll and libQt6Core.a.
Some of this renaming was done for MinGW plugins and shared libraries,
but not for modules in 9b0e23ef8a.
Extract the duplicate code and apply it to all shared libraries built
by Qt on Windows. Adjust the prefix and suffix accordingly, depending
on whether we use MinGW or not.
Amends 9b0e23ef8a
Task-number: QTBUG-84886
Change-Id: I5a8618597df5f57ce256739adced3f24eb13dac7
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The change fixes the labels to show up correctly in the configure
summary.
It also allows enabling the sanitizer via the feature flags, e.g.
-DFEATURE_sanitize_address=ON.
Finally the qtbase sanitizer option is saved in QtBuildInternalsExtra
so that repos built after qtbase have the same sanitizer options
enabled.
Change-Id: Ic9d9e3ce3c7ebbc244ced2e6d163d1ac8ee06b12
Fixes: QTBUG-84721
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
To successfully link plugins of a static Qt build into a Qt project we
need to generate .prl files for the plugins.
Task-number: QTBUG-84781
Change-Id: I1406052f2269050aa7cbe6aa2b546bece1c68467
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In qmake land the define is set in mkspecs/common/macx.conf which
means it should be public for all Qt consumer apps as well, not just
internal targets. Make it so.
Amends 17be43c58e
Task-number: QTBUG-83929
Change-Id: I9f9d7dfca24b54977cb8364723c3618d3fec2e73
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The large file flags in qmake land are set in the
mkspecs/features/unix/largefile.prf file, which is loaded by qmake
when a CONFIG += largefile entry is written by configure into
qmodule.pri.
This essentially makes them global flags for all private Qt targets
because qmodule.pri is a global file loaded load(qt_build_config)
Thus assign the flags onto the PlatformCommonInternal target instead
of the PlatformModuleInternal one.
One peculiarity though is that in qmake land these flags are also
applied when building examples as part of the main Qt build. This
is because qt_build_config loads qmodule.pri even for an example,
because qmake sees it as part of the overall Qt build.
The flags are not applied by qmake if the example is built in
a different standalone build dir not part of the Qt buil dir.
We don't do that in the CMake build, and thus examples will never
have those flags.
Task-number: QTBUG-83929
Change-Id: If653a669b4835aadd1de84acb477c375ab523909
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The qt_internal_apply_gc_binaries function should apply both compile
and link flags, not just link flags.
The flags should be applied publically to all consumers of Bootstrap
regardless if the gc_binaries feature is enabled.
The flags should be applied publically to Core only in case if the
feature is enabled (aka for static builds only).
Change-Id: Id42af0d9b527004d74c04eff2c9e3c2be1e76aac
Fixes: QTBUG-84461
Task-number: QTBUG-83929
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This mirrors what qt_tool.prf does.
Task-number: QTBUG-83929
Change-Id: I892a3f5f62d461456abfa414718fcc4c4c05c012
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Like in the qmake build, we now set the target description of a Qt tool
to a value, different from the description of the Qt libraries.
Fixes: QTBUG-84900
Change-Id: I93419ddd513c83fe8488e70b5a8328cadc3541c7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In a qmake build this file serves the purpose of setting the right
prefixes for the build directory's qmake binary. This can be used to
build Qt repositories other than qtbase, esp. in a top-level build.
In the CMake build, we don't have qmake top-level builds, and we do not
support building Qt repositories with the build directory's qmake binary
(exception: non-prefix build).
To build a Qt module or user project with qmake, the installed qmake
must be used.
This fixes qmake for non-prefix top-level CMake builds.
Change-Id: Ibd10c36e8359225553d782d0c8117760db9f3370
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In static builds, due to our CMake design for auto-linking plugins
being incorrect we sometimes cause link failures on Linux in leaf
modules, because the link line order is incorrect.
So far such failures were fixed by explicitly modifying the order of
libraries on the link line in each failing CMake project.
This proves to be problematic because the failures appear in seemingly
random integrations that don't even touch the build system parts.
Until we fix the design, another less performant but more
general / safe way is to increase the link interface multiplicity,
which causes a cycle of libraries to be repeated more than 2 times
on the link line, thus giving the ld linker more chances to figure out
which symbols are needed for linking.
Implement this for Linux static builds to avoid random integration
failures for people that know nothing about this issue.
The link multiplicity for all qt modules is increased to 3, thus
QtGui would be repeated 3 times on the link line of each dependent
library. The value is also configurable via the
QT_LINK_CYCLE_MULTIPLICITY cache variable.
Task-number: QTBUG-83498
Change-Id: I2fd2bb2b5e7fec4e3ef5d1194668b524d20f7067
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
To be in line with the qmake build we drop the "d" suffix for MinGW
debug libraries unless the debug_and_release feature is enabled.
Task-number: QTBUG-84781
Change-Id: I1b83492bff561d3d7647dde467931ec3866ae940
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When doing a top-level build,
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX is not set in the
top-level scope. There's no point really in using the relocatable
path anyway, given this will only be displayed once when either
configuring qtbase or qt6.
Just use CMAKE_INSTALL_PREFIX directly.
Change-Id: Idb7e1953745f55048c42155868c2dd9384876c7c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
It used to be called HAVE_DASH_UNDEFINED_ERROR, but that always
cause Coin to print the compile check as the first build error snippet
because it contains the word "error", and whenever you get emails from
Gerrit the first snippet is always this compile check.
Rename it to avoid confusion in emails and Coin status reports.
Change-Id: I5487623abf9df177b100d2b45635688504f0e25a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
For static builds of Qt we installed the plugins into the lib
directory. However, they are expected in the plugins directory tree.
This happens, because we pass a value of an uninitialized variable to
ARCHIVE DESTINATION in the qt_install call in qt_internal_add_plugin,
and CMake defaults to "lib".
This flaw was introduced in b42feb02ce with the following intent:
"This patch also changes add_qt_plugin() to use the value provided in
INSTALL_DIRECTORY for ARCHIVE_INSTALL_DIRECTORY if no value is provided
for the latter."
The patch changed the value of arg_ARCHIVE_INSTALL_DIRECTORY but
missed to set the variable archive_install_directory, which is
actually used in the qt_install call.
We now directly set archive_install_directory and remove the unused
archive_install_directory_default variable.
Task-number: QTBUG-84781
Change-Id: Ifd0475d8452272e8765bf42fd912a45cfa3dbbd1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Because find_package usually creates targets in a local scope,
qt_generate_prl_file fails to generate a .prl file that has
references to generator expressions like
"$<TARGET_FILE:Freetype::Freetype>" which references targets
that are not found in that specific scope (e.g Freetype target is
present in qtbase scope, but not qtsvg scope).
This happens in static top-level Qt builds, and thus fails the
configuration. While we try to figure out how to fix this adequatly,
don't generate .prl files in such a configuration.
Task-number: QTBUG-84874
Change-Id: I69cf0ad1419d21e3676e1374624601f00936c405
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Users / developers usually configure a single example. The CI
can still continue to explicitly configure and build all examples.
Task-number: QTBUG-84471
Change-Id: I1c9ac857e7ad0e5602037265194f0a6742386b51
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Fixes the 'add_library cannot create imported target "dbus-1"
because another target with the same name already exists' error
when doing top-level static builds.
It's caused by the loading of Qt6DBus dependency when configuring
qttools.
Task-number: QTBUG-84874
Change-Id: Ia84ed460c4ce25de45fb41cb13edd0e63a276f11
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
qmake_use.prf understands the _DEBUG and _RELEASE suffixes for
QMAKE_LIBS_XXX entries. The CMake configuration "Debug" is considered
for the _DEBUG entries, "Release" and "RelWithDebInfo" for _RELEASE.
The qt_lib_XXX_private.pri files are now generated in multiple steps:
1. The QT_LIBS_XXX information is generated per $<CONFIG> and written to
.cmake files.
2. A preliminary qt_lib_XXX_private.pri file is generated, containing
only configuration-independent data.
3. A custom command runs the QtGenerateLibPri.cmake script that combines
the files from step 1 and 2 into the final qt_lib_XXX_private.pri
file.
The same is done for mkspecs/qmodule.pri.
To be able to trigger custom commands from header modules, which are
interface libraries, we introduce one XXX_timestamp ALL target per
header module that creates a timestamp file. To that XXX_timestamp
target we add the pri file generation target as dependency.
Fixes: QTBUG-84348
Change-Id: I610f279e37feeb7eceb9ef20b3ddfecff8cfbf81
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The module pri files of internal modules did not expose any include
paths. They must have both, the public and the private include paths.
Task-number: QTBUG-84781
Change-Id: I3cbe94d4e49c754e49d26b00012e668b0afbdc8f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
MinGW plugins should not have the lib prefix in the shared library
names. Do this manually for a couple of libraries, and also for the
generic qt_add_cmake_library function.
Amends 9b0e23ef8a
Change-Id: I1cfaf8fc046f86edd3e755adfa599aa0aa854ee3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This is needed so that other repos other than qtbase (like qtopcua)
can still find_package(WrapOpenSSL) successfully.
The path needs to be converted to a CMake path, to avoid issues
on Windows with backslashes.
Change-Id: I3d7652d93110f6b8f39a58a6c28aef6c7471aea7
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT might be empty on the
first configuration, but because QtBuildInternalsExtra sets the
CMAKE_INSTALL_PREFIX, a second reconfiguration of a test would
stop setting the fake install prefix.
After some further consideration, there's no need to set the local
fake prefix conditionally, we can always do it (unless explicitly
opted out).
This makes sure that a reconfiguration of a test doesn't suddenly
install into the Qt prefix again.
Amends 37b132cd4e
Task-number: QTBUG-84346
Change-Id: Ic61aefe18418658455d8cdb9ebe6bcbcb8d67c99
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
They are not necessary, and they conflict with what qttools generates.
Fixes: QTBUG-82133
Change-Id: I4a1273d694626345b32b45c653dd31d3b78621eb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Now that the whole file is not included when doing standalone tests,
the conditions are not needed anymore.
Change-Id: I49ddd2fc4a8327e09529948785f40cda5dedbb11
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Three different people have encountered the issue that calling
calling qt-cmake on a project prints 1000 inclusion lines of the same
qt toolchain file, and then CMake bails out saying can't find the
CMAKE_MAKE_PROGRAM Ninja.
This happened because people accidentally called qt-cmake to configure
qtbase (instead of just cmake), which created a toolchain file that
chainloads itself recursively.
Error out when configuring qtbase, and when using the generated
toolchain file in the case when it would try to include itself.
The solution is to remove the qtbase CMakeCache.txt file, and
configure qtbase again, so it generates a proper qt.toolchain.cmake
file.
If somebody feels enthusiastic, they can move the check into the
qt-cmake and qt-cmake-private shell scripts, and error out before the
qtbase/CMakeCache.txt is polluted with the wrong toolchain file.
That is left for people that feel more comfortable with bash and batch
scripting.
Change-Id: If518c94791fe7c30731e6e462e347f26a5213c64
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Include headers in .pri files should point to the framework Headers
dirs.
The module name in the .pri file is not versioned when it's a bundle.
Paths to system frameworks in .prl files should instead be replaced
with -framework Foo flags.
Change-Id: Ia353d033799fae40a1bc55fad6f86b2c8ef76c56
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
We reported that double-conversion was found on macOS if the std
library supported sscanf_l and _snprintf_l, but that's different
from what qmake does.
This caused not to compile and link the bundled double-conversion
sources, and caused tst_qvariant to fail when doing double conversions
on macOS.
Remove the extra config tests, and make it work like in qmake, so that
the bundled code is used instead. This makes tst_qvariant pass.
Amends 729a73a9cf
Change-Id: I7ddaed5fe6916f483fb3de1962657d7fb6fb40be
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
And also fix qt-cmake-standalone-test to work for prefix builds.
The gist of it is that we have to protect tests not to be installed
into the Qt install prefix, but we also have to make sure that the
CMAKE_INSTALL_PREFIX is not changed globally (via cache value),
so that reconfiguration still works.
This took way too long to figure out.
Amends d6272d774c
Fixes: QTBUG-84346
Change-Id: I18c29574c9957fe05b86f701c8c14ec07e0f045b
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Qml tests currently don't expose a CMake target, so no
dependency should be added to a non-existent target.
Make sure to add the check target only if the test was previously
added.
Fixes configurtion failure of qtdeclarative tests.
Amends 873aa682c5
Change-Id: Ic8bbfe668c00c1ce05f1e1dfe5494dafd91dd7b8
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This patch allows tools to be built for the target platform when the
QT_BUILD_TOOLS_WHEN_CROSSCOMPILING parameter is set at configuration
time.
To avoid naming conflicts, the target tools are suffixed with "_native".
The qt_get_tool_target_name() function can be used to get the tool name
for both scenarios (cross and non-cross compilation).
Extend pro2cmake to refer to the right target name for tools.
The relevant write_XXX functions have a new target_ref parameter that
will be "${target_name}" for tools and literally the target name for
everything else.
Fixes: QTBUG-81901
Change-Id: If4efbc1fae07a4a3a044dd09c9c06be6d517825e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Given a test named "tst_qdrag", you can run "ninja tst_qdrag_check"
to build and run the test.
Change-Id: I47dccb39dd60fca9cb07ff9af9fb739b293c5aaf
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This avoids issues with some special characters and spaces.
Change-Id: I6b7cedbe2c9663f62fae104488454faebab52ce0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMake sets "lib" as default prefix for Windows-GNU platforms.
Change-Id: I49e3123c385610307c84c584a21f5f3827a6fafd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The function name has been changed upstream (3.18).
Change-Id: I76a26cdc8de71dffa5402a7c7423006a7a01552e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's only calls were with the PUBLIC argument, so remove the argument
both in the declaration and call sites, and just return the public
dependencies.
Fix up the names of the variables as well.
Amends b56dc55c3a
Change-Id: I830c1894376d0d3a2eb2bd4ffa38a1b3b3066292
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Previously we checked the LINK_LIBRARIES property of the main module
target, but we should instead use the values of
INTERFACE_LINK_LIBRARIES set on the FooPrivate module.
Because both versionless targets and private targets are interface
libraries, we need to properly differentiate between them when
following versionless targets to their main associated target.
To do that, instead of using string comparison, export an additional
private _qt_is_versionless_target property, and query that.
Also make sure to set and export the _qt_config_module_name property
on the FooPrivate targets.
Also make sure to APPEND to EXPORT_PROPERTIES rather than override
(looking at you QtFeature.cmake).
Task-number: QTBUG-75666
Change-Id: Ia3261e218840e9f5217ab49755e8c876560e294d
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Needed to avoid linker warnings transformed into errors, when linking
QtWebEngine with qmake mixing.
ld: warning: linking against a dylib which is not safe for use in
application extensions:
The flag is added to libraries and plugins, unless opted out.
CMake equivalent of 944110089d
Task-number: QTBUG-83929
Task-number: QTBUG-75666
Change-Id: I3e9acca4712c9a266bf54c6e35e2fd2c0096692b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Qt module targets now export the "_qt_config_module_name" property,
which contains the module's name in qmake land. This can be different
from the lower case target name (e.g. Test vs testlib). This exported
property is used when retrieving the dependencies of a module outside
of qtbase.
The property's name is a bit odd and lower case, because we want to be
able to set it on INTERFACE_LIBRARY targets, for instance header
modules. This CMake pecularity is described in
https://gitlab.kitware.com/cmake/cmake/issues/19261
Fixes: QTBUG-84287
Change-Id: I4a75af3ebeabebc56a0f77d464e45ab7fd81eafa
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This reverts commit e875f45805.
Reason for revert: syncqt creates a master header that includes
the *Depends header. Therefore we must always create the *Depends
header. Ignore for now that *Depends headers are empty and pointless
for module headers.
Change-Id: I1dcc836788b3d46c4f1b504d2d64e9eb67b66206
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For now, we have to turn off the 3rdparty lib generation code for
qt_lib_XXX.pri files, because it's broken for NMC if the 3rdparty
libraries have different binaries per config.
The actual fix is more involved.
Task-number: QTBUG-84348
Change-Id: I863e69085b68c0dbbb3f6c415111bc255799e155
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Introduce a qt_finalize_module function that is called as a
CMakeLists.txt finalizer and call qt_generate_module_pri from there.
This is done in preparation for writing the QT.XXX.depends entries to
the module pri files, because we must do this after all dependencies
have been added.
Change-Id: Ia61db73383541651389fd647523ef535792874d4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If an OUTPUT_DIRECTORY option is provided, it should be used instead
of discarding it.
Change-Id: Ie53b56616f16589f7c05ff9378d7ba2e2ba34726
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The module pri files are supposed to add their public features to the
global QT_CONFIG variable.
Change-Id: I9a1719f897747a1d89011b1f1231c05a23539def
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Avoid writing module_plugin_types-NOTFOUND into the module .pri files.
Change-Id: I2fed7b0d1c21e2233eebcaca419f522a07d22af4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For modules that are not yet ported to CMake and that use
QMAKE_USE += libfoo
we need to provide the information about libfoo in the qt_lib_XXX.pri
files.
Also, we now generate qt_ext_XXX.pri files for bundled 3rdparty libs.
Task-number: QTBUG-75666
Change-Id: I9e4b057a197554ecb37c294c0bf09e2a2b3aa053
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Calling cmake --install . only installs a single configuration.
To install both debug and release artifacts, the install
invocation needs to be done for each configuration.
To keep the Coin instruction code simpler, delegate the looping
over configurations to a custom CMake script, and use it in the
Coin instructions.
Replace all cmake --install calls in the instructions with calls
to either call_host_install.yaml or call_target_install.yaml.
The path to the script depends on whether we are building
qtbase or another module. In the former case the script should
be called from the build dir, otherwise from the install dir.
The other distinction is whether the host or target env prefix
needs to be added.
Task-number: QTBUG-80900
Change-Id: Ied4bf739e2b1a2307f22fc79c1cfad746c8cbc44
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When using Ninja Multi-Config, we don't want to install a "Release"
moc.exe, and then override it with a "Debug" moc.exe.
Because it doesn't seem possible to exclude installation of targets
per configuration, put the non-main configuration tools into
configuration specific subfolders like "bin/Debug", so no overriding
happens upon installation.
Introduce a new function qt_get_install_target_default_args() which
returns install destination arguments for consumption in qt_install()
calls. The function adds the config-specific suffix to the destination
for the appropriate configs.
Each call to qt_install *adds* new rules for installation,
which means that export registration needs to happen only on the first
call.
Make sure qt_add_tool doesn't ask qt_add_executable to install
yet again, to create duplicate rules.
Apply the same install arguments logic to qt_add_executable calls.
Task-number: QTBUG-80900
Task-number: QTBUG-80901
Change-Id: I3e732d27dba5bf5f8059d2878ef1e425237d383a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Thus we will build both Release and Debug configurations in Coin
when cmake --build . is executed, mimicking qmake's make which
builds both configurations in debug_and_release.
Task-number: QTBUG-80900
Change-Id: If48aca249eb84e690d3f9d51a733b3a25df1f7ca
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Where NMC is the CMake Ninja Multi-Config generator.
The first use case is to allow building standalone tests with one
configuration even if Qt was build with multiple configurations.
Another use case is for regular Qt consumers that might use the
generated qt-cmake shell script which does not have the generator
specified (as opposed to qt-cmake-private).
Another detail is to use the first configuration from the initial
Qt configurations list (CMAKE_CONFIGURATION_TYPES) when building
standalone tests with a single config generator, so that it doesn't
default to Debug, but rather to the provided first configuration.
This matches qmake behavior, where on Windows with a
debug_and_release configuration, tests are still built against
release.
Task-number: QTBUG-80900
Change-Id: I0da91c1f91095332cfe9e38d17f440aad6a09d15
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Set the target property INTERFACE_MODULE_IS_HEADER_ONLY for
header-only modules, and only create *Depends header files if this
property is falsy.
Change-Id: Ic6b100787d18b3ff1f7b9d0f2b5c744018b1f295
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This value is the equivalent of qt_module.prf's MODULE_INCNAME and can
be used to specify a name for the module's include subdirectory. The
default is Qt<ModuleName>.
The include name is stored in the module's target property
MODULE_INCLUDE_NAME.
Change-Id: Ie6c8f6882ee2c3db78884ae5781593c803be3c05
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And enable the same default when building Qt itself (it's implicit).
Allow opting out on a target-by-target basis, by using the public
qt_disable_utf8_sources() API call.
Change-Id: Ifc19a744d57b96b1c74a6926a0c6628c2a820464
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Before, we were setting those properties only for Qt modules.
Now, Qt executables and plugins have a full VERSIONINFORMATION
resource on Windows.
Also, extend the CMake API with the possibility to pass target
information to modules, plugins and tools. This will be used in a
subsequent commit.
Change-Id: I2bb8d3637569e0eaec76f56331bc23282285d872
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way.
The following story inspired this change.
If a user wants to build a Qt repo into a different install prefix
than the usual Qt one, this will fail configuration because we
look for various things like syncqt, qdoc, etc relative to
CMAKE_INSTALL_PREFIX, which will now point to a different location
where none of the above tools are located.
The intent for such a use case is to support building Qt packages with
Conan, which sets a random install prefix when configuring a repo.
The idea is to derive the qt prefix dynamically from the
QtBuildInternals package location. Essentially it's a reverse relative
path from the QtBuildInternalsConfig.cmake file to the install prefix
that was specified when initially configuring qtbase.
Once the dynamic prefix is computed (so we know where the possibly
relocated Qt is), we can find tools like syncqt and qdoc.
This is an initial attempt to support a use case like that.
More design work will probably needed in case if tools / libs need to
be found in a location different than the Qt install prefix (so
support for multiple install prefixes / search paths).
An example of such a case would be when building qtdeclarative and
qtquickcontrols2 as Conan packages in one go. Most likely the
qmltyperegistrar tool will be located in the random install prefix
set by Conan, so building qtquickcontrols2 might fail due to not
finding the tool in the original Qt install prefix.
As to the implementation details, the change does the following:
- Dynamically computes and sets the
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when
find_package()'ing QtBuildInternals. It's an absolute path
pointing to where the relocated Qt is.
- When building qtbase this variable is not yet available (due
to QtBuildInternalsExtra not existing), in that case we set
the variable to the absolute path of CMAKE_INSTALL_PREFIX
(but only for the initial qtbase configuration).
- Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used
for standalone tests purposes. It's not needed now that we compute
the location of the Qt prefix dynamically.
- The Unixy qt-cmake and qt-cmake-private shell scripts now
use a relative path to find the toolchain file we created.
- The toolchain file also dynamically computes the location of the Qt
packages, and adds them to CMAKE_PREFIX_PATH.
- A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding
tool locations, mkspecs dir, path environment setup for tools, etc.
- Some places still use CMAKE_PREFIX_PATH in the following cases
- When determining paths while configuring qtbase (valid cases)
- When I wasn't sure what the behavior should be, so I left them
as-is (an example is documentation generation, do we want to
install it into the random Conan prefix, or into the main prefix?
Currently it installs in the random prefix).
Note that relocating a Qt installation does not work for non-prefix /
non-installed builds, due to hardcoded paths to include directories
and libraries in generated FooTargets.cmake files.
Task-number: QTBUG-83999
Change-Id: I87d6558729db93121b1715771034b03ce3295923
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This is needed for building Qt plugins with qmake against other
CMake-built modules.
Change-Id: Ibd6ad0b08645c798be74285b24f71add947bea88
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Otherwise when applied to bundled 3rd party library C files,
the MinGW build fails when compiling src/3rdparty/md4c/md4c.c.
Change-Id: Ia522b10aa69aa15f239d20c65e31c84edbccee6d
Reviewed-by: Simon Hausmann <hausmann@gmail.com>
Due to the install prefix being changed for standalone tests,
the correct $qt_prefix/bin folder was not added to the PATH
environment variable when running tests.
Make sure to always include the the original qt install prefix,
even if a different install prefix is specified when configuring
standalone tests.
Amends 39090ea15c
Change-Id: I22aab732bb2bb679074a811d28d8209e1d535df3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Gets rid of mismatch warnings when looking for various
ECM packages like XCB.
Change-Id: I0bf4db993195993df7789c032454b7883e8efd35
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Enable sse2 and fpmath for modules when appropriate, the logic
is a port of the code in mkspecs/features/qt_module.prf.
Fix qdrawhelper.cpp to always be compiled when using GCC with a
special case. pro2cmake.py failed to handle the source subtraction
correctly.
Fixes: QTBUG-83791
Task-number: QTBUG-75578
Change-Id: Ibe32a250b266d580ad21f6c55f09fd03a14ceb82
Reviewed-by: Simon Hausmann <hausmann@gmail.com>
... and update handling of CLASS_NAME in qt_internal_add_plugin
Change-Id: Iec8e5f9f80df02c9ba21648535872988839f4b64
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Traditionally, these make targets generated HTMLs
and QCH only. This change fixes the dependency for
these targets to ensure that behavior.
Fixes: QTBUG-83877
Change-Id: Ic7c8afe5853d33fc4cc4cfd996f87e5f65df31ed
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
It broke configuration of qtwayland standalone tests, due to qtwayland
doing 3 separate qt_find_package(Wayland) calls with the same package
but different arguments in 3 different directory scopes.
The top scope didn't have PROVIDED_TARGETS argument. The rest of the
scopes did have the arguments with either Server or Client, but because
of the debug behavior above being enabled by default the dependencies
weren't registered in the Qt6WaylandClientDependencies.cmake file (and
the server equivalent).
The registration didn't happen due to the skipping logic, when a package
is found and the targets already exist.
This led to standalone tests failing to configure because they tried
linking against non-existent Wayland::Client and Wayland::Server
targets.
This reverts commit dd7e40b108.
Change-Id: I60e358a4891b84ecec0e127d9de8ab9747a6ab24
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Simon Hausmann <hausmann@gmail.com>
Previously configuration of standalone tests might have failed
due to CMake trying to create files in the /usr/local default
prefix.
Make sure to use a fake prefix in the binary dir instead,
unless another prefix is explicitly specified.
Change-Id: Icfcb32285aa5596abf1a918396b26673880a8d27
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
CMake IMPORTED targets should be namespaced so that CMake knows that
the name refers to a target and not a file.
Use the existing WrapXXX naming scheme where applicable.
Fixes: QTBUG-83773
Change-Id: I5b0b722c811200c56c260c69e76940a625228769
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add a SKIP_AUTOMOC argument to qt_add_3rdparty_library and use it in
BundledHarfbuzz.
Change-Id: Ie4aa61639a5ab64f286ac539989572a9ae6bc3d5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Due to the wrong string comparison, we were writing out the wrong
architecture for the arm64 builds to the deployment settings json file.
This leads to androiddeployqt tool not being able to locate the
stdlibc++.
Change-Id: I3d13b14c27f043445bf46aaca0e9f862f6ca84e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This patch allows all the sqldrivers to be built as a standalone project.
It is not possible to build each plugin separately due to the configuration
features definition being located in the sqldriver's folder CMakeLists.txt.
In other words, the project needs to be generated from the
src/plugins/sqldrivers/CMakeLists.txt file.
Fixes: QTBUG-82962
Change-Id: If41c7e3827589391830a894a9c998d2e56239562
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Without this behavior enabled by default it is currently not possible to
build QtVirtualKeyboard as a static build. We run into the error where
cmake is trying to promote the targets to be global due the XCB library
already being found by one of the modules in QtBase.
In case we wish to disable this fix, any module can simply specify
QT_FIND_PACKAGE_DISABLE_DEBUG_BEHAVIOR=ON during configuration time.
Change-Id: Id7f2ad12ddea941dda754361660c7606439cd5a4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This feature is Windows-only and must be turned on manually.
For MSVC it sets the MSVC_RUNTIME_LIBRARY target property.
For MinGW it adds the -static linker flag.
Change-Id: I9da3b88d545b34bc34a3a80301b2dd1b5986fa88
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This patch adds a publicly callable qt6_add_plugin() API to create
plugins. This API is meant to cover cases such as the plugandpaint
example.
This patch also renames qt_add_plugin to qt_internal_add_plugin in order
to avoid clashes with the public API. To avoid breaking the existing
projects, a compatibility wrapper function is enabled by default unless
QT_DISABLE_QT_ADD_PLUGIN_COMPATIBILITY is specified.
Fixes: QTBUG-82961
Change-Id: If5b564a8406c90434f1bdad0b8df76d3e6626b5f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Consider a negated feature config value like the following:
qt_feature_config("foo" QMAKE_PUBLIC_QT_CONFIG NEGATE)
If this feature was disabled, it would turn up in both,
enabled_features and disabled_features of module .pri files.
Also, QT_CONFIG would contain foo.
Expected however is that QT_CONFIG contains no-foo, and only
disabled_features contains foo.
Fix this by prepending a "no_" prefix to the value, similar to the
"no-" prefix in the qmake build. The qt_correct_config function was
adjusted to recognize "no_foo" and translate it to the qmakeish
"no-foo" config value.
Config values that start with "no_" but do not correspond to a feature
are left untouched. You can still have values like
"no_valley_too_deep" or "no_mountain_too_high".
Change-Id: I23d8b18c84e04ea6dfa25cc6ccd8f7e86211b144
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra
config file step.
Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Since there's no way to register callbacks or to store functions to be
called later in CMake, the only way to isolate the quick compiler
behavior for qt_add_resources() is to wrap it in a conditional check.
As soon as someone loads Qt6QmlMacros, the variable will set and the
functionality will be available.
Change-Id: I5fbdf2966e7dfdc734512a5b2b973e0ace9da5df
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Once we can require CMake 3.17 everywhere, we can remove the variable
set up from QtSeparateDebugInfo.cmake.
Change-Id: I91572583654054f5fa47ac1e41be23050a5a8c0b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In a non-prefix build, the module .pri files must end up in the
mkspecs/modules subdirectory of qtbase's build directory.
Change-Id: I241f4e274d31de7c1e3c2fa8e5e26fb8747f11c5
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Implemented some necessary functionality to generate correct .pri
information, so that qmake can build modules.
Task-number: QTBUG-75666
Change-Id: I63281adfef3d01385928b1d8c4be0b32ac97c4d7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This commit also adds a qt_finalize_module function that is called for
every Qt module after all link dependencies have been added.
Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We don't want people accidentally installing tests into the
Qt prefix.
Change-Id: Ic99492559875f753897a83af162253cac846a8a5
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The install prefix in such a case is the qtbase build dir,
and not the qt6 top-level build dir. This caused issues with
certain incorrect paths being generated, including a broken
qt-cmake-standalone-test script, as well as upon reconfiguration
determining that a non-prefix build should be installed.
The fix for a non-prefix build is to check explicitly for
the qtbase build dir. This works both for super and non-super
builds.
Task-number: QTBUG-83496
Change-Id: Ida2393176c4c81da767023ff48159afdedfb0a19
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Instead of using CMAKE_INSTALL_RPATH to embed an absolute path
to prefix/libdir into all targets, use the more sophisticated aproach
that qmake does.
For certain targets (modules, plugins, tools) use relative rpaths.
Otherwise embed absolute paths (examples, regular binaries).
Installed tests currently have no rpaths.
On certain platforms rpaths are not used (Windows, Android,
iOS / uikit).
Frameworks, app bundles and shallow bundles should also be handled
correctly.
Additional rpaths can be provided via QT_EXTRA_RPATHS variable
(similar to the -R option that configure takes).
Automatic embedding can be disabled either via QT_FEATURE_rpath=OFF
or QT_DISABLE_RPATH=ON.
Note that installed examples are not relocatable at the moment (due
to always having an absolute path rpath), so this is a missing feature
compared to qmake. This is due to missing information on where
examples will be installed, so a relative rpath can not be computed.
By default a Qt installation is relocatable, so there is no need to
pass -DQT_EXTRA_RPATHS=. like Coin used to do with qmake e.g. -R .
Relative rpaths will have the appropriate 'relative base' prefixed
to them (e.g $ORIGIN on linux and @loader_path on darwin platforms).
There is currently no support for other platforms that might have a
different 'relative base' than the ones mentioned above.
Any extra rpaths are saved to BuildInternalsExtra which are re-used
when building other repositories.
configurejson2cmake modified to include correct conditions for the
rpath feature.
It's very likely that we will need a new qt_add_internal_app()
function for gui apps that are to be installed to prefix/bin.
For example for Assistant from qttools. Currently such apps
use qt_add_executable().
The distinction is necessary to make sure that relative rpaths are
embedded into apps, but not executables (which tests are part of).
Amends e835a6853b
Task-number: QTBUG-83497
Change-Id: I3510f63c0a59489741116cc8ec3ef6a0a7704f25
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The CMAKE_INSTALL_RPATH cache var had the PATH type, which made
CMake transform the value into an absolute path, getting rid of the
$ORIGIN value.
Fix that by changing the cache var type to STRING.
Also clean up the all-caps commands, add a usage example and print
the install RPATH.
Change-Id: Ibf40cfde4283369ddfcf52609143799cc8e47d68
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This is required to support QtVirtualKeyboard's third party OpenWnn
library.
Change-Id: I64b6a2b6b6b0259bea5aa249a8c901def31f916c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If a find_package() in a try_compile project doesn't find a package,
and we then link against a non-existent target, the configuration
failure of the compile test also fails the configuration of the
project.
To avoid that, separate library targets from non-targets, and make sure
to only link against the targets if they exist.
pro2cmake now outputs modified compile test project code which iterates
over targets and non-target libraries, and links against them when
needed.
Change-Id: Ib0f4b5f07af13929c42d01a661df2cabdf9b926b
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
In Coin when provisioning for Android, we download and configure
the OpenSSL package, but don't actually build it. This means that
find_package(OpenSSL) can find the headers, but not the library,
and thus the package is marked as not found.
Previously the openssl_headers feature used the result of finding
the OpenSSL package, which led to it being disabled in the above
described Android case.
Introduce 2 new find scripts FindWrapOpenSSL and
FindWrapOpenSSLHeaders. FindWrapOpenSSLHeaders wraps FindOpenSSL,
and checks if the headers were found, regardless of the OpenSSL_FOUND
value, which can be used for implementing the openssl_headers feature.
FindWrapOpenSSL uses FindWrapOpenSSLHeaders, and simply wraps the
OpenSSL target if available.
The find scripts also have to set CMAKE_FIND_ROOT_PATH for Android.
Otherwise when someone passes in an OPENSSL_ROOT_DIR, its value will
always be prepended to the Android sysroot, causing the package not
to be found.
Adjust the mapping in helper.py to use the targets created by these
find scripts. This also replaces the openssl/nolink target.
Adjust the projects and tests to use the new target names.
Adjust the compile tests for dtls and oscp to use the
WrapOpenSSLHeaders target, so that the features can be enabled even
if the library is dlopen-ed (like on Android).
Task-number: QTBUG-83371
Change-Id: I738600e5aafef47a57e1db070be40116ca8ab995
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The previous approach didn't work for prefix builds. While a target
might be excluded from building via EXCLUDE_FROM_ALL property, when
calling make install it would still try to install the target and
thus fail.
It's not possible to modify an install() command in a post-processing
step, so we switch the semantics around.
pro2cmake will now write a
qt_exclude_tool_directories_from_default_target() call before adding
subdirectories. This will set an internal variable with a list
of the given subdirectories, which is checked by qt_add_executable.
If the current source dir matches one of the given subdirectories,
the EXCLUDE_FROM_ALL property is set both for the target and the
qt_install() command.
This should fix the failing Android prefix builds of qttools.
Amends 622894f96e
Change-Id: Ia19323a2ef72a3fb9cb752ad2d4f2742269d11c4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
list(JOIN) removes a layer of escaping, which force doubling up
on the backslashes. Instead use string(REPLACE) thus making the
escaping a bit saner.
Change-Id: Ie3daf0112dd09fbcbaf8798552949470952611c9
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
On Android, check_language() reports that the languages are supported,
but enable_language fails afterwards.
On Linux it causes issues with the PCH. The PCH file might contain
a Clang pragma, even though the C++ compiler is GCC. Presumably due
to finding a Clang Objective-C compiler.
Change-Id: I1b4c54459772c089e7f6350872c87af52ad72a37
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
configurejson2cmake handles the 'static' and 'shared' features now.
There's no need to special-case it anymore.
Change-Id: I956e9f46ebe022b1da862e986ec05f41e1e804e0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
configurejson2cmake handles the 'rpath' feature now. There's no need
to special-case it anymore.
Change-Id: I9aa9c9acdeb586de09d8a8d269909f8acb02e40a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add -Wno-error=format-overflow. This is similar to what is done in
qt_common.prf, however we don't turn the warning off completely.
For now at least.
Change-Id: I93c20064759dea43309c3a17de4d733ede9ca2cb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Starting with CMake 3.18, there is PCH support for darwin multi-arch
builds, like iOS simulator_and_device builds.
Also enable PCH for Objective-C++ files when the support is there.
To enable PCH for Objective-C++, we need to do enable the OBJCXX
language as well, but conditionally, because on non-darwin platforms
the language is probably not available.
Introduce the qt_enable_cmake_languages() macro which is called
automatically by qt_build_repo_begin().
Change-Id: I0e7f44be6577ac54ce940470036626409920e272
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Some library entries in configure.json have a test entry.
An example is assimp in qtquick3d.
qmake tries to find the library via the sources section, and then tries
to compile the test found in config.tests/assimp/assimp.pro while
automagically passing it the include and link flags it found for assimp.
We didn't handle that in CMake, and now we kind of do.
configurejson2cmake will now create a corresponding
qt_config_compile_test call where it will pass a list of packages and
libraries to find and link against.
pro2cmake will in turn generate new code for the standalone
config.test project. This code will iterate over packages that need to
be found (like WrapAssimp) and then link against a list of passed-in
targets.
In this way the config.test/assimp/main.cpp file can successfully
use assimp code (due to propagated include headers).
qt_config_compile_test is augmented to take a new PACKAGES argument,
with an example as follows
PACKAGES PACKAGE Foo 6 COMPONENTS Bar
PACKAGE Baz REQUIRED
The arguments will be parsed and passed to the try_compile project,
to call find_package() on them.
We also need to pass the C/C++ standard values to the try_compile
project, as well as other try_compile specific flags, like the
toolchain, as given by qt_get_platform_try_compile_vars().
Change-Id: I4a3f76c75309c70c78e580b80114b33870b2cf79
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The target may not be defined which causes error:
get_target_property() called with non-existent target "qtwaylandscanner".
Change-Id: I58a9122456ccbbbb8fc9f0adce3b7ddcc985e6a4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Installing headers is not supported for 3rd party libs (we don't run
syncqt, we don't install headers for 3rd party libs to
prefix/include).
Remove the unnecessary condition.
Change-Id: I46e9af7a7ca9de0138666b0d0faffc86238672ba
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When creating the include/QtShaderTools/QtShaderToolsDepends file
in QtPostProcess.cmake -> qt_internal_write_depends_file(),
we decide which include files to append based on link dependencies
starting with Qt::, which happens to match 3rd party targets like
Qt::BundledSpirv_Cross which doesn't expose headers in the
prefix/include dir.
Mark all bundled targets with the QT_MODULE_SKIP_DEPENDS_INCLUDE
property to exclude them from being added to Depends files.
This should fix static builds of qtquick3d which includes
<QtShaderTools/QtShaderToolsDepend> which tries to include a
non-existent <QtBundledSpirv_Cross/QtBundledSpirv_Cross>.
Change-Id: I9dcff1e2ab721a7c21fcff3fda0faf8d023d60ba
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The path where we install plugins is usually
prefix/plugins/plugin_type/plugin_name
The plugin_type should not be escaped, so it should be used verbatim
(no escaping of slashes or dashes)..
So far it seems the only weird plugin types are wayland plugins which
contain dashes, like wayland-shell-integration, and the sub-ios plugin
which has a slash (platforms/darwin).
For cmake properties we use the escaped names.
This should fix tests in wayland where the wayland plugins can't be
found.
Change-Id: I93406731b8c872a82c0f247f5b7c6bdab4875455
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Qt uses the qtNomakeTools() function to mark a directory which will
not be built as part of the default target. This is especially
important when cross-compiling (to iOS for example) because the build
process might fail.
The condition for not building these "GUI tool sub-directory projects"
is the absence of the "tools" value in qmake's QT_BUILD_PARTS
variable.
Introduce a QT_NO_MAKE_TOOLS CMake variable. If the value is true,
it's equivalent to "tools" not being present in QT_BUILD_PARTS.
Introduce qt_exclude_tool_directories_from_default_target().
It's the qmake counter part to qtNomakeTools().
Teach pro2cmake to generate it where appropriate.
Change-Id: If2e5958d91847ab139af0e452608510286e73fa0
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
