We never passed a valid target name to qt_apply_rpaths.
This amends fde98f7794.
Task-number: QTBUG-85399
Change-Id: I1c023ce30a3a8b5ec43d020373960d19fe20f59a
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
We need to call qt_apply_rpaths for targets that are created with
qt_internal_add_app too. This is in line with what qt_app.prf does.
Task-number: QTBUG-85399
Change-Id: If5ffb05cca191c6cae9a330e1f4556d342a68ff8
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
AndroidManifest.xml file and the Android plugin already has a way
to provide commandline-arguments to app with the tag
"android.app.arguments". This change allow to set it from qmake/cmake
and allow Qt Creator to use that.
Task-number: QTCREATORBUG-23712
Change-Id: I3e680f40fd36ba6aaac7f344fb9509d2c3360e74
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
For prefix builds we need to install the file.
Amends db21bad936.
Change-Id: Ia8e859dc048cc4bd74eb95ed0d2adce9c6b11902
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Fix name of target so that qtattributionsscanner actually generates content.
Change-Id: Ie42067928d7cd1de02fa4ae92a0f5ef54bd54a5c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Make sure the executable path contains an .exe on Windows.
Change-Id: I972a3aaf1ad0510525ebfcc84e8c589f555c6d00
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
C4180, C4458 were disabled already in 2012, in commit 6668f5becf.
C4577 was disabled due to QtScript being compiled without exception
support in commit 97d7d80e73.
Anyhow, Qt Script is now officially gone in Qt 6, and Qt headers
do work just fine with C4180. Finally, C4458 is nowadays a W4 warning,
so not enabled in the first place.
Task-number: QTBUG-82615
Change-Id: I2f9b8e858817876b069a166129fbfac7ef3587a0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Configure Qt with -DQT_FEATURE_headersclean=ON to enable the
check. There will be separate target for each module include
(e.g. QtCore_header_check), but the check will also be done
when the module is built for the first time.
There are notable differences to the qmake version:
- the build does not pick up anymore default defines or flags from
the module, or Qt. Instead options like -fPIC they have to be listed
explicitly. Also for this reason, we have to skip the vulkan-related
headers from the check, since vulkan/vulkan.h is not necessarily
in the compiler's default search path.
- some checks for nowadays unsupported compiler versions are
removed.
- -Wdouble-promotion -Wshorten-64-to-32 is not added for clang
builds; the qmake code path did never enforce that on CI
machines (it was non-Apple clang only), and the check currently
fails on these configurations.
Fixes: QTBUG-82615
Change-Id: I1cd303677b1472116910b6c27748f96436feb35e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use any definition from pkgconfig for the EGL compilation test.
Change-Id: I95c659b87ab7b0de81f000e3f52195161a493ef5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Very simple AUTODETECT expressions worked fine, but expressions with
parentheses, for example, were not correctly evaluated.
Change-Id: Ibec4fa55474e149a701f861838fdea41d31beca0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
