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>
This commit also adds a qt_finalize_module function that is called for
every Qt module after all link dependencies have been added.
Change-Id: I489d188d05e368208a8a62828bb12fb395df54bc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The install prefix in such a case is the qtbase build dir,
and not the qt6 top-level build dir. This caused issues with
certain incorrect paths being generated, including a broken
qt-cmake-standalone-test script, as well as upon reconfiguration
determining that a non-prefix build should be installed.
The fix for a non-prefix build is to check explicitly for
the qtbase build dir. This works both for super and non-super
builds.
Task-number: QTBUG-83496
Change-Id: Ida2393176c4c81da767023ff48159afdedfb0a19
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Instead of using CMAKE_INSTALL_RPATH to embed an absolute path
to prefix/libdir into all targets, use the more sophisticated aproach
that qmake does.
For certain targets (modules, plugins, tools) use relative rpaths.
Otherwise embed absolute paths (examples, regular binaries).
Installed tests currently have no rpaths.
On certain platforms rpaths are not used (Windows, Android,
iOS / uikit).
Frameworks, app bundles and shallow bundles should also be handled
correctly.
Additional rpaths can be provided via QT_EXTRA_RPATHS variable
(similar to the -R option that configure takes).
Automatic embedding can be disabled either via QT_FEATURE_rpath=OFF
or QT_DISABLE_RPATH=ON.
Note that installed examples are not relocatable at the moment (due
to always having an absolute path rpath), so this is a missing feature
compared to qmake. This is due to missing information on where
examples will be installed, so a relative rpath can not be computed.
By default a Qt installation is relocatable, so there is no need to
pass -DQT_EXTRA_RPATHS=. like Coin used to do with qmake e.g. -R .
Relative rpaths will have the appropriate 'relative base' prefixed
to them (e.g $ORIGIN on linux and @loader_path on darwin platforms).
There is currently no support for other platforms that might have a
different 'relative base' than the ones mentioned above.
Any extra rpaths are saved to BuildInternalsExtra which are re-used
when building other repositories.
configurejson2cmake modified to include correct conditions for the
rpath feature.
It's very likely that we will need a new qt_add_internal_app()
function for gui apps that are to be installed to prefix/bin.
For example for Assistant from qttools. Currently such apps
use qt_add_executable().
The distinction is necessary to make sure that relative rpaths are
embedded into apps, but not executables (which tests are part of).
Amends e835a6853b
Task-number: QTBUG-83497
Change-Id: I3510f63c0a59489741116cc8ec3ef6a0a7704f25
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The CMAKE_INSTALL_RPATH cache var had the PATH type, which made
CMake transform the value into an absolute path, getting rid of the
$ORIGIN value.
Fix that by changing the cache var type to STRING.
Also clean up the all-caps commands, add a usage example and print
the install RPATH.
Change-Id: Ibf40cfde4283369ddfcf52609143799cc8e47d68
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This is required to support QtVirtualKeyboard's third party OpenWnn
library.
Change-Id: I64b6a2b6b6b0259bea5aa249a8c901def31f916c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The previous approach didn't work for prefix builds. While a target
might be excluded from building via EXCLUDE_FROM_ALL property, when
calling make install it would still try to install the target and
thus fail.
It's not possible to modify an install() command in a post-processing
step, so we switch the semantics around.
pro2cmake will now write a
qt_exclude_tool_directories_from_default_target() call before adding
subdirectories. This will set an internal variable with a list
of the given subdirectories, which is checked by qt_add_executable.
If the current source dir matches one of the given subdirectories,
the EXCLUDE_FROM_ALL property is set both for the target and the
qt_install() command.
This should fix the failing Android prefix builds of qttools.
Amends 622894f96e
Change-Id: Ia19323a2ef72a3fb9cb752ad2d4f2742269d11c4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
