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>
