HEADER_MODULE argument is passed to qt_generate_module_pri_file from
the qt_internal_add_module function, but the property means that the
module is an interface library. So it makes sense to replace this
argument with the reading of the target TYPE.
Change-Id: I1d8cd2ff732f526975cde6bdd4783fee44c8bd98
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Matches qt_generate_module_pri_file and allows using genexes in the
content of the file.
Change-Id: I5ee7a973d3e27a721e31315d3ebe2c88ffa1db42
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The same way qt_generate_module_pri_file does it.
Change-Id: I42047ce7d23e8a289535041ccace8b0f0140ea12
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
It's perfectly possible to create static plugins in an otherwise shared
Qt build, but the logic to import these plugins into applications was
assuming a fully static Qt build. We now handle this more granularly.
Change-Id: Iacfa72f04c7918613b50ca87cf123e7f4c0841d5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make the target purpose more understandable from its name.
Change-Id: I4f4a56fd3ef338b728d4a81edc2df32cada97f6c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The include paths in QMAKE_INCDIR_FOO entries in qt_lib_XXX.pri files
are filtered to not contain implicit include directories.
We must enclose the regular expression with ^...$ to avoid catching too
many paths like any subdirectory of /usr/include.
Fixes: QTBUG-104736
Change-Id: I2d40e6ec6d3f3421d591fed90b4dd9ebbbeb59f4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously, this was only supported when cross-compiling, but that's an
unnecessary limitation. Instead, make it possible to build the "host"
tools (notably qmake) even when they've been found elsewhere due to
QT_FORCE_FIND_TOOLS=ON and a supplied QT_HOST_PATH.
The combination of QT_FORCE_FIND_TOOLS and QT_FORCE_BUILD_TOOLS set to
ON is useful for developers who touch content that ends up in the
bootstrap library.
QT_BUILD_TOOLS_WHEN_CROSSCOMPILING is deprecated in favor of
QT_FORCE_BUILD_TOOLS.
[ChangeLog][CMake] QT_BUILD_TOOLS_WHEN_CROSSCOMPILING has been
deprecated in favor of QT_FORCE_BUILD_TOOLS. The latter can be used in
combination with QT_FORCE_FIND_TOOLS and QT_HOST_PATH to use tools from
a host Qt even for a non-cross build and still build the tools.
Fixes: QTBUG-99683
Change-Id: I0e5f6bec596a4a78bd3bfffd16c8fb486181f9b6
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
ANDROID_NATIVE_API_LEVEL is an alias for ANDROID_PLATFORM and the
Android's CMake docs [1] uses directly ANDROID_PLATFORM so let's use
that as well. Also, NDK r23b seems to have removed the part of code from
android.toolchain.cmake that handles ANDROID_NATIVE_API_LEVEL to set
the correct value to ANDROID_PLATFORM.
With this change, CMake will pass the value from the configure argument
-android-ndk-platform as -DANDROID_PLATFORM instead of
-DANDROID_NATIVE_API_LEVEL. Otherwise, if if -DANDROID_NATIVE_API_LEVEL
is passed directly to CMake, it should work as before.
[1] https://developer.android.com/ndk/guides/cmake#build-command
Pick-to: 6.3
Task-number: QTQAINFRA-4837
Change-Id: I5c21af53ac91e11a27c4b033313d22d1115c1abc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This hasn't worked for some time. It's not in our CI and I don't think
it was working at all. When I tried to build it, I ran into several
problems with C++17 and an Internal Compiler Error I did not have any
interest in working around.
After discussing with the Intel compiler team, it was decided that
fixing those issues in the old compiler is not going to happen. Instead,
their recommendation is to adopt the new LLVM-based compiler, which
the last commit added support for.
This commit does not remove qmake support for the old ICC. It's possible
someone is using qmake with a non-Qt6 project and ICC.
Change-Id: Icb2516126f674e7b8bb3fffd16ad6350ddbd49e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This includes a few cleanups to our .cmake files where it was easier to
combine existing sections of Clang / AppleClang that no longer needed to
be distinct.
icpx could be replaced with a shell script:
exec `basename $0`/clang++ --intel "$@"
tst_qnumeric is not passing
FAIL! : tst_QNumeric::classifyF() Compared values are not the same
Actual (qFpClassify(tiny / two)): 2
Expected (FP_SUBNORMAL) : 3
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(344)]
FAIL! : tst_QNumeric::classifyD() Compared values are not the same
Actual (qFpClassify(tiny / two)): 2
Expected (FP_SUBNORMAL) : 3
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(344)]
FAIL! : tst_QNumeric::floatDistance(denormal) Compared values are not the same
Actual (qFloatDistance(from, stop)): 0
Expected (expectedDistance) : 4194304
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(408)]
FAIL! : tst_QNumeric::doubleDistance(denormal) Compared values are not the same
Actual (qFloatDistance(from, stop)): 0
Expected (expectedDistance) : 2251799813685248
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(408)]
P
Change-Id: Icb2516126f674e7b8bb3fffd16ad59431e8c3379
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Do not read the target property LINK_LIBRARIES from interface libraries
as this leads to errors with CMake 3.16.
This amends commit 326b91ea78.
Pick-to: 6.2
Change-Id: I44251c7633d5ecd977cd05746ac311dd1285d1e3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The .pri files for public Qt modules were missing run_depends entries.
Those entries are used by qmake when linking plugins of a static Qt
build. In shared builds, run_depends entries are used to decide whether
to add the -rpath-link argument to the linker. In that matter,
run_depends entries serve a similar purpose as CMake's
IMPORTED_LINK_DEPENDENT_LIBRARIES.
In Qt5, run_depends entries consist of the qmake values QT_PRIVATE and
QT_FOR_PRIVATE.
QT_PRIVATE contains the Qt modules that are privately linked to the
public module, and QT_FOR_PRIVATE are the dependencies of the private
module. That loosely translates to LINK_LIBRARIES of the public module
and INTERFACE_LINK_LIBRARIES of the private module.
Private modules whose public counterparts are already public
dependencies don't have to be added to run_depends.
Pick-to: 6.2
Fixes: QTBUG-84310
Change-Id: If7025c98ea462a2d5a143202df3d98d88e4fee08
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Because otherwise we may end up with trailing backslashes
Pick-to: 6.2 6.2.0 6.1
Change-Id: I7ad24ec34c35f0a7b32241751bbcd2b26a8a23ea
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Module may have specific module include name that should be taken into
account when specifying module include directories in different places.
The INTERFACE_MODULE_INCLUDE_NAME module property name is aligned to
the common naming rules and the property is used to preform include
paths instead of the direct use of the module name.
Add additional paths generated by qt_internal_module_info to keep them
consistent across all cmake files.
Pick-to: 6.2
Change-Id: I4c94017abc322c48616f47e65e371bd863bb087d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
After introducing the _qt_module_has_headers target property, it's
better to replace the INTERFACE_MODULE_HAS_HEADERS use by
_qt_module_has_headers since properties duplicate each other.
Pick-to: 6.2
Change-Id: I4d62ed71b8ed8263f51d8575628693122580b4a7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
If Vulkan headers are present on the system when qtbase is configured,
QtGui and QtOpenGL should be compiled with Vulkan support.
If a user project uses a Qt built with Vulkan support, but their system
is missing Vulkan headers, the project configuration needs to succeed.
The project will get compilation errors if it uses Vulkan headers, but
that's intended.
This use case was broken when fixing Vulkan to be found when building
Qt for Android.
Fix the regression with a combination of things
1) Mark the WrapVulkanHeaders package as optional (already the case)
2) Use the include directories directly when compiling Gui and OpenGL
3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to
consumers only if the target exists. It won't exist if Vulkan
include dirs are not found
This also requires some changes in pri and prl file generation.
For prl file generation, we don't want to link to the
WrapVulkanHeaders target, so we filter out all dependencies that
use TARGET_NAME_IF_EXISTS for anything that calls
__qt_internal_walk_libs which includes qt_collect_libs.
For pri files, we make sure to generate a uses=vulkan/nolink clause
by inspecting a new _qt_is_nolink_target property on the target.
We also don't add include dirs to the pri file if the new
_qt_skip_include_dir_for_pri property is set.
This is intended for Vulkan, because there is separate qmake logic to
try and find the include dirs when configuring a user project.
As a drive-by, fix nolink handling for WrapOpenSSLHeaders.
Amends bb25536a3d
Amends 7b9904849f
Pick-to: 6.2
Fixes: QTBUG-95391
Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Quote the paths after "-L".
Get MSVC’s implicit link directories from $ENV{LIB}.
Fix some issues cause by Inconsistent case.
Amends 2c49f85380
Fixes: QTBUG-95198
Pick-to: 6.2 6.1
Change-Id: Ie82f10b088e2764396377726340509f24a4ae8e7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QtPriHelpers copies the logic related to the module OUTPUT_NAME to
produce a module identifier. Since the module identifier should be
equal to OUTPUT_NAME it makes sense to reuse the property and
deduplicate logic.
Amends 8aee7c6b29
Pick-to: 6.2
Fixes: QTBUG-94568
Change-Id: I8d9c04273e4cdb1a2e6a3b0db3ddf52e008c0cf7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Set the correct value to the _qt_config_module_name property at the
internal module creating step instead of appending _private suffix when
generating .pri files.
Amends 425ff34aa1
Pick-to: 6.2
Fixes: QTBUG-94568
Change-Id: I6fa8089358bc638668e313c98c3aee680bf7ec2a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For Apple's frameworks it's possible to include header files using the
following assumption:
If the framework name is "MyFramework" then
'#include <MyFramework/frameworkheader.h>' will work without specifying
the include path explicitly. This is broken for internal modules since
they use the framework name with the 'Private' suffix.
This uses the module name instead of the target name as a framework
name.
Amends edbe0eb335
Task-number: QTBUG-87775
Change-Id: I0592a28d0768724b6e10ca81aa7cefb0a3699a5e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In MSVC static build, if we build Qt with 3rdparty library (e.g. zstd),
cmake will add"zstd" (without "-l" prefix) to Qt6Core.prl. Then we
use this Qt to build a qmake project, compilation will fail due to
missing zstd.obj. Without "-l" prefix, qmake will treat "zstd" as an
object file instead of a library.
Library names in qt_module.pri and qt_lib_*_private.pri are also
missing "-l" prefix.
This is because on most compilers, CMAKE_LINK_LIBRARY_FLAG equals
"-l". But on MSVC, it is an empty string. So we should pass
"-DLINK_LIBRARY_FLAG=-l" for MSVC.
Also add "-L/path/to/library" if the library path is not in default
linker search directories. This will write un-relocatable paths to prl
files only when using 3rdparty libraries to build Qt statically. Usually
it's not a problem.
In addition, CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is also empty on
MSVC. So The third argument of "$<FILTER>" is empty, it is an invalid
generator expression. This means no include dir will be written to
qt_module.pri and qt_lib_*_private.pri on MSVC. So only use "$<FILTER>"
when CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES is not empty.
Pick-to: 6.1
Change-Id: Ib66f95dc09cf920363a4b9338fb97747dd2f8ab7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Since the information about framework is performed in multiple places
it's quite hard to control its consistency. This moves the obtaining
of framework related information to the common function and adjusts
the use of the information across the repo.
Change-Id: I1f488d41dcea75a1e8c361926792a6b7c45e5a3f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When dealing with a universal build of Qt, we would end up
using the QT_ARCH as the architecture for user projects,
but this architecture is always the primary one that Qt
was configured with.
Instead of relying on QT_ARCH, we start writing QT_ARCHS
(plural) to qconfig.pri, based on CMAKE_OSX_ARCHITECTURES,
and then use that to initialize QMAKE_APPLE_DEVICE_ARCHS.
We then resolve the active arch using uname -m, matching
what CMake does.
We still feed all the available architectures to the
Makefile or Xcode project, so that the user can build
for any of the available architectures without needing
a reconfigure.
Fixes: QTBUG-93760
Change-Id: I0d338241ba4d944ca36d85371e9c4df7dbc4f269
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously the plugin .pri files that CMake generated for qmake
consumption contained an '-' to exclude the plugin from
auto-importing only if the plugin type was generic or a platform
plugin.
Now that plugin projects that should be excluded have a proper
DEFAULT_IF FALSE
clause, we can simply query for the defaultness of the plugin
to know whether to exclude it in the generated .pri file.
This fixes an issue with Qt static builds and qtvirtualkeyboard.
The vkb plugin was not excluded and thus any simple QtGui app
linked to the vkb plugin in a static qmake project. This led to linker
issues because the vkb plugin also depends on a vkb quick plugin which
is not listed as a dependency.
Augments 76230d9879
Amends c975c35eae
Pick-to: 6.1 6.1.0
Fixes: QTBUG-92529
Task-number: QTBUG-87861
Change-Id: I9671f6504374cf0799289bbe19110e01c129402e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
A few configure defines get changed:
QMAKE_WASM_PTHREAD_POOL_SIZE is now QT_WASM_PTHREAD_POOL_SIZE
QMAKE_WASM_TOTAL_MEMORY is now QT_WASM_INITIAL_MEMORY
QMAKE_WASM_SOURCE_MAP_BASE is now QT_WASM_SOURCE_MAP_BASE
device-option EMSCRIPTEN_ASYNCIFY=1 is QT_EMSCRIPTEN_ASYNCIFY=1
To create source maps for debugging. use
device-option QT_WASM_SOURCE_MAP=1
Task-number: QTBUG-78647
Change-Id: If9f30cd7fb408c386d6d69b5f7b1beecf1ab44b5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Just like config_module_name is appended by "_private" in the case of
internal module pri, replace module_includes with the private one.
It fixes the issue where a pro file that uses an internal module pri
does not build due to missing paths to private headers.
Fixes: QTBUG-89961
Change-Id: Ice16a1e9f709d29454f1ddf5b954673cc06a88bb
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Jaeyoon Jung <jaeyoon.jung@lge.com>
QMake libraries that contain dashes are referenced by QMAKE_USE as is,
but the corresponding QMAKE_LIB_<NAME> variable must be normalized to
contain underscores.
Example from the qmake build:
./mkspecs/modules/qt_lib_waylandclient.pri
11:QT.waylandclient.uses = wayland-client xkbcommon wayland-cursor
./mkspecs/modules/qt_lib_waylandclient_private.pri
12:QMAKE_DEPENDS_WAYLAND_CURSOR_CC = WAYLAND_CLIENT
13:QMAKE_DEPENDS_WAYLAND_CURSOR_LD = WAYLAND_CLIENT
15:QMAKE_LIBS_WAYLAND_CURSOR = -lwayland-cursor
Pick-to: 6.0
Change-Id: If31bd45764d52f97d80d6388503008dc1ffb16ab
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Those entries were always empty. The INTERFACE_QT_MODULE_USES property
was never set.
Map each public dependency to its qmake lib name and place this value
into the module's QT.<module-name>.uses variable.
Take into account the "_nolink" target modifier and translate it to
qmake's "/nolink".
Pick-to: 6.0
Fixes: QTBUG-88951
Change-Id: Ib6ef65b842a1fe1da3ade55867583343b4ee76ee
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Rename QT_QMAKE_LIB_TARGETS_foo to QT_TARGETS_OF_QMAKE_LIB_foo, because
we want to introduce the counterpart QT_QMAKE_LIB_OF_TARGET_bar in a
subsequent commit.
Pick-to: 6.0
Task-number: QTBUG-88951
Change-Id: I33f00f4fe65c5977da6e74c632ebeab3b891c89a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For consistency, apply the following renamings:
QT_NO_MAKE_EXAMPLES -> QT_BUILD_EXAMPLES_BY_DEFAULT
QT_NO_MAKE_TESTS -> QT_BUILD_TESTS_BY_DEFAULT
QT_NO_MAKE_TOOLS -> QT_BUILD_TOOLS_BY_DEFAULT
BUILD_EXAMPLES -> QT_BUILD_EXAMPLES
BUILD_TESTING -> QT_BUILD_TESTS
This should help to better convey the difference between "BUILD" and
"NO_MAKE".
To configure tests, but not to build them by default, pass the
following to CMake:
-DQT_BUILD_TESTS=ON -DQT_BUILD_TESTS_BY_DEFAULT=OFF
Analoguous for examples:
-DQT_BUILD_EXAMPLES=ON -DQT_BUILD_EXAMPLES_BY_DEFAULT=OFF
Tools can be excluded from the default build with:
-DBUILD_TOOLS_BY_DEFAULT=OFF
The variable BUILD_TESTING is still available and initialized with the
value of QT_BUILD_TESTS.
Pick-to: 6.0 6.0.0
Change-Id: Ie5f29dfbdca8bfa8d687981dfe8c19c0397ca080
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Plugins will no longer get .pri files generated in non-static builds.
Header modules are now marked in the .pri files as CONFIG += no_link.
Pick-to: 6.0 6.0.0
Fixes: QTBUG-88221
Change-Id: I06e31fa970ad021261c43ca3acd88055cc4c9555
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The QT.foo.module entry is used for linkage, so we shouldn't
add it for header only modules.
Change-Id: Ibb6e7ab08083ccab11d7e060f35c54153e3751c0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The flags go before the library in the final linker line, as opposed
to the dependencies declared in LIBS.
This allows us to declare the flags for the entrypoint
in the project file of the entrypoint, instead of in
a standalone prf.
Change-Id: I35c054fe9fdaa6add7cd0e8ba3f7304f975ff80f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
On the qmake-side we had exports, but they were quoted.
Change-Id: I95af4b927079691cab6403fec850f345ba181a00
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Makes the diff between Qt 5.15 and 6.0 easier to read, to see what's
missing.
Change-Id: Idf8aa17b3ab8494f6855c172665423a53ca8a024
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The value is useful for QPA plugins built in repos other than qtbase,
to decide if it should be a default plugin or not.
Currently useful for qtwayland.
Also export a qmake value assignment when doing static builds, just
like src/gui/configure.pri does.
Change-Id: I1253f1a7e178b24b16e2615ba20d1e92b0b87b1a
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
qmake treats internal modules as just the regular module file,
but with a _private suffix, as opposed to the current cmake
logic, that treats it as the private module file, resulting
in missing e.g. the Qt.foo.module entry.
Change-Id: Id55ca4c23921656d5abfd1d0fdf6430d4fe120bf
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
These were introduced in
675805e9eb and
b9c85d6b0e
They should be exported if they were set.
Change-Id: Ieec565980ba148f675f84dcdd7c19894e349085f
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The value is used by mkspecs/features/mac/default_post.prf and
ultimately by xcodebuild to decide which arch and SDK to build
against.
For a simulator_and_device build, no value needs to be set as far as
I can see.
Task-number: QTBUG-87218
Change-Id: I41992bec6b16aadfd87c3f7c10653a6094e76d3e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
