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>
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>
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>
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>
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>
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>
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>
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>
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>
... and update handling of CLASS_NAME in qt_internal_add_plugin
Change-Id: Iec8e5f9f80df02c9ba21648535872988839f4b64
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
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>
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>
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>
