Fix library substitution again which broke when I merged all the
library related pieces of information.
Keep Qt and 3rdparty libraries separate so that dbus does not get
mapped into Qt::DBus (or the other way around).
Make names in helper.py more consistent while at it.
Change-Id: I5e5bf02bdabf8bafe991c5701deca76bde4df2c3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Tested with MinGW 7.3.0 64 from Qt 5.12 installation.
The CMake 3rd party libraries I used from hunter project (with some
package, and target names changes)
Change-Id: Ie89555a6cd8bdb7182f9b2dd2c3c39784c523ead
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously we just recorded that Gui has to link against
Vulkan::Vulkan_nolink, but if an application consumed Gui, it wouldn't
find that target.
We need to record that if a module links against Vulkan_nolink, and
then generate a find_dependency(Vulkan) call in the module config
file.
We also have to assign the _nolink interface library to an export
(the Qt5 one), so that it gets installed as a target.
Change-Id: Icbc29ff4161ab18fdd162196ae128e29c1ee8c80
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Generate CMake config files which export Qt targets with a Qt:: prefix
(i.e. without a major version suffix in the namespace)
Change-Id: Ia07f98be6d0e24c196e3880b7469f1f0c6232c06
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Merge all data related to mapping libraries into one data structure
in helper.py.
Use that data for everything related to library mapping.
This change enables way more features now like e.g. adding find_package
calls into generated files.
Change-Id: Ibbd2a1063cbeb65277582d434a6a672d62fc170b
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Do not set properties of packages to type OPTIONAL. That is the default
anyway.
Update generator script and generated files.
Change-Id: I7a4d043b69c93ce8c2929a2e27ac6a07e4e6d8cc
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Also needs the include/ from the top-level binary dir added to the
include path.
Change-Id: I7e0d82a2ee24d9bf9ffe9da5fd02b3b223fd48e7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is needed because dependencies added after add_qt_module with extend_target
are currently not taken into account.
Task-number: QTBUG-75538
Change-Id: I2c72207fb88b2480e41a2c8550978fb194275617
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* When using a sysroot, just setting CMAKE_PREFIX_PATH to the
QT_HOST_PATH is not sufficient in finding for example Qt5CoreTools
because the QT_HOST_PATH would be prefixed by the sysroot. So this
patch switches the mode to also enable looking outside of the sysroot.
(done by Alexandru)
* Once the Qt5CoreToolsConfigVersion.cmake was found, the built-in check
for 32 vs. 64 bit compatibility by looking at the provided
CMAKE_SIZEOF_VOID_P (4 when target is armv7 for example) and comparing
it against the void* size used when building the tools would fail.
Explicitly unsetting CMAKE_SIZEOF_VOID_P disables this check, and
that's fine as we're not interested in any exported library targets --
where this could cause problems -- but merely programs to run.
Change-Id: If2931dad023e39a3dbdaa17ac095131ad2c0ca60
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Behave like qmake and link against libGL simply. This happened in
offscreen.pro implicitly through QT += gui-private and needs to happen
explicitly here by using the CONFIG += opengl equivalent: WrapOpenGL.
Change-Id: I396c2256c89f4560bb7f936f7540b33c754b9eda
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is because some FindPackage may produce some targets only on some
platforms - e.g. qt_find_package(OpenGL) needs to define
the provided target OpenGL::GLX which will only exist on linux but
is required by various CMakeLists.txt files.
Change-Id: I74515470f5d56c246f489df74901ad4223a92a70
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This fixes the build when GLX is available.
In the .pro files as well as the .cpp files the condition of enabling
GLX support is based on the Qt feature system (xlib && opengl &&
!opengles2). The change to replace the !opengles check with a cmake
target check is incomplete for two reasons:
(1) the target check would _never_ succeed because there was no
find_package() call in scope that would create the target.
(2) when the target is found, the .cpp code that checks for the
features would fail, because that continues to use the !opengles2
condition -- the preprocessor can't know about cmake targets.
So this reverts commit 1361cf5d50 and
instead calls for an investigation why in Ville's machine desktop gl was
disabled.
Change-Id: I9a7957224f81b800282c260dee8abcd421fdbc9e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
We don't need the _dummy.cpp files in the build anymore that don't exist
anyway.
Change-Id: I70e12dd39009c86779f3863c945e835b76cb24f6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The dev->wip/cmake merge is done already.
Change-Id: Ia6b17ac633cd2bcd1e9f6e96a0a0bf33042ed63b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This way we don't need to run rcc during cmake time
Change-Id: Id92111bce6c2b6798f3b18552cea82c8d07c4fc0
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Also make the tool package depend on all tool packages that correspond
to the qt module dependencies.
So find_package(Qt5Widgets) implicitly calls find_package(Qt5WidgetTools).
And find_package(Qt5WidgetsTools) will call find_package for
Qt5GuiTools, and Qt5CoreTools.
This enhances the user experience, so that in modules like qtsvg, you
don't have to specify both find_package(Qt5Widgets) and
find_package(Qt5WidgetsTools), but only the former.
Or when cross building, you only need to specify Qt5WidgetTools, to get
both Core and Gui tools.
Change-Id: Ib1c5173a5b97584a52e144c22e38e90a712f727a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
This change introduces a new function called qt_find_package()
which can take an extra option called PROVIDED_TARGETS, which
associates targets with the package that defines those targets.
This is done by setting the INTERFACE_QT_PACKAGE_NAME and
INTERFACE_QT_PACKAGE_VERSION properties on the imported targets.
This information allows us to generate appropriate find_dependency()
calls in a module's Config file for third party libraries.
For example when an application links against QtCore, it should also
link against zlib and atomic libraries. In order to do that, the
library locations first have to be found by CMake. This is achieved by
embedding find_dependency(ZLIB) and find_dependency(Atomic) in
Qt5CoreDependencies.cmake which is included by Qt5CoreConfig.cmake.
The latter is picked up when an application project contains
find_package(Qt5Core), and thus all linking dependencies are resolved.
The information 'which package provides which targets' is contained
in the python json2cmake conversion script. The generated output of
the script contains qt_find_package() calls that represent that
information.
The Qt5CoreDependencies.cmake file and which which dependencies it
contains is generated at the QtPostProcess stop.
Note that for non-static Qt builds, we only need to propagate public
3rd party libraries. For static builds, we need all third party
libraries.
In order for the INTERFACE_QT_PACKAGE_NAME property to be read in any
scope, the targets on which the property is set, have to be GLOBAL.
Also for applications and other modules to find all required third
party libraries, we have to install all our custom Find modules, and
make sure they define INTERFACE IMPORTED libraries, and not just
IMPORTED libraries.
Change-Id: I694d6e32d05b96d5e241df0156fc79d0029426aa
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
CMake will now generate config and target files for each module that
provides tools. As a result, namespaced global targets such as
Qt5::moc or Qt5::rcc can be made available.
Third party projects that require just these tools, and not the Qt
modules themselves, should specify CMAKE_PREFIX_PATH pointing to the
installed Qt location, and call find_package(Qt5CoreTools),
find_package(Qt5GuiTools), etc.
It is also possible to call
find_package(Qt5Tools REQUIRED Core Widgets) where the last option
is a list of modules whose tools should be imported.
Note that all the tools are in the Qt5::
namespace and not in the Qt5CoreTools:: or Qt5WidgetsTools::
namespace.
This commit also changes the behavior regarding when to build tools
while building Qt itself.
When cross compiling Qt (checked via CMAKE_CROSSCOMPILING) or when
-DQT_FORCE_FIND_TOOLS=TRUE is passed, tools added by add_qt_tool will
always be searched for and not built.
In this case the user has to specify the CMake variable QT_HOST_PATH
pointing to an installed host Qt location.
When not cross compiling, tools added by add_qt_tool are built from
source.
When building leaf modules (like qtsvg) that require some tool that was
built in qtbase (like moc), the module project should contain a
find_package(Qt5ToolsCore) call and specify an appropriate
CMAKE_PREFIX_PATH so that the tool package is found.
Note that because HOST_QT_TOOLS_DIRECTORY was replaced by QT_HOST_PATH,
the ensure syncqt code was changed to make it work properly with
both qtbase and qtsvg.
Here's a list of tools and their module associations:
qmake, moc, rcc, tracegen, qfloat16-tables, qlalr -> CoreTools
qvkgen -> GuiTools
uic -> WidgetTools
dbus related tools -> DBusTools
Task-number: QTBUG-74134
Change-Id: Ie67d1e2f8de46102b48eca008f0b50caf4fbe3ed
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Update required dependencies.
Add section on how to build vcpkg on macOS.
Fix some typos.
Lower required CMake version.
Inform how to bypass annoying ninja reconfiguration issue.
Change-Id: Ia35bd4329c2cbb9857157cdc33b098f5adb04a35
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
With qmake if we don't find a system package, we use the bundled one.
With CMake we don't provide a bundle freetype, hence it's required
to find a system one (or custom provided one).
Change-Id: I00a5e2ac55459957dae0729f89bafa792a102152
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Otherwise add_qt_executable will still link against Core,
and thus building qmake in a static build will fail.
Amends a1752276e0
Change-Id: Iebbdf9d0a2808a9eaeffdf8fbdb44ff5e2920f3b
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Qmake should not rebuild all the code in QtCore, but currently it does.
When linking against QtCore, all the symbols get duplicated. A clever
linker will "deduplicate" the symbols again, so this actually works
with shared Qt builds, but it fails for static builds.
Do not rely on the linker being clever and just do not link Qt at all
for qmake.
Change-Id: I0f79ed9176a19ee884dd425e5f23c26cf69dc422
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
When building qtsvg, the file gets picked up while doing
find_package(Qt5Gui) and fails the configuration phase.
Remove it as it was done before.
Change-Id: I3499e33ecc129e31f8d3b144ee6370b2a9bb4f9a
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Use absolute paths for source files, and relative paths plus a correct
working directory for output files.
This is required to work around a limitation of the dbusxml2cpp tool
where it splits a command line option on a colon ":". Windows paths
contain colons, and that breaks the internal logic of the tool when
passing absolute paths.
Change-Id: Ic653f1317ae4f68bb2f488c117fe48c34310c76e
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Applications that have the WIN32_EXECUTABLE property set,
must have a WinMain function. In qmake's case, this function
is provided by the qtmain static library.
Until that is implemented in CMake land, disable the property on
Windows for all qt executables. This fixes the linker issues while
building examples.
Task-number: QTBUG-75195
Change-Id: I323d4dd899f716cd6b9b7f4b5ecb76b22f462fc4
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
