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>
