This maps the behavior of mkspecs/features/qt_common.prf and enables the
use of C++17 for example in Android, where the toolchain supports it
anyway.
Change-Id: I41f4bdb160a3929e2fb78f36efb1ad5f2ad391a5
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This is needed because the ported over requires() clauses from qmake
to CMake are executed before qt_repo_build(), which means that all the
custom platform variables that we set (like LINUX, APPLE_OSX) need
to be available immediately after finding BuildInternals.
Change-Id: I7345b69edf72c266508846766e64f42c99862d1d
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Previously you had to make sure to use DISABLE_TOOLS_EXPORT
in an add_qt_module call if the tools are built after the module,
as well as to manually call qt_export_tools after all associated
tools are built.
This was needlessly complex, especially for people that are porting
a repo with tools for the first time.
The tools package creation is now automatically done at QtPostProcess
step, so there is no need to use either DISABLE_TOOLS_EXPORT or
qt_export_tools() manually.
DISABLE_TOOLS_EXPORT is now a no-op, and will be removed once all repos
are updated not to use it.
Change-Id: I965b0d3a8a0cb908afae87b047083ed7bea9f02f
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Some modules define their own manually-maintained lists, and we can rely
on the headers generated by each module to include in the pch as well
e.g. QtCore/QtCore.
There's also e.g. QtWidgetDepends for QtWidgets, but this only
works for modules, not for tools, examples or other applications.
For now we'll use the Qt<Module>/Qt<Module> headers for the
modules we depend on.
Building with PCH can be disabled with -DBUILD_WITH_PCH=NO, and it only
works for versions of CMake newer than 3.15.20190829.
Change-Id: Iae52bd69acfdfd58f4cd20d3cfa3c7f42775f732
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
As with qmake, you configure with or without -nomake tests -nomake
examples, and the choice is propagated to other repositories.
Do the same for CMake. It's still possible to opt out to build one
or the other by passing -DBUILD_TESTING=OFF -DBUILD_EXAMPLES=OFF
on the command line, which takes precedence over the value saved to
QtBuildInternalsExtra.
Change-Id: If0fbfa938d88309e7969c9bacc8d0bf86548bf5e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
It should happen after qmake is built, to make sure that the target is
made global, otherwise when cross-building qtbase in another build tree,
the configuration phase will fail due to not finding qmake.
qmake was accidentally exported before if you configured qtbase twice,
because the tool was kept around in a cache variable, the second
configuration actually recreated the CoreToolsConfig.cmake file to
contain qmake as well.
Change-Id: I6941e83f7d6bd03c56de120fba1d18e50c4af0e4
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Add QtAutoDectect cmake which has routines to handle the vcpkg detection
as well as set up some android configuration parameters. The latter will
contribute towards keeping the cmake configuration commands shorter when
targeting android.
Change-Id: I721291c8dce39b5c298565a46867ddcab2df90e8
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The Qt::Platform target includes the mkspecs/$spec directory, which we
must unconditionally install as long as we use it.
Change-Id: I272650a887b5b0b3bd868524784dca65b76b02d9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
If VCPKG_ROOT is defined, let's use it and chainload any previously set
toolchain file. The detection of vcpkg support via the VCPKG_ROOT
environment variable is per vcpkg documentation, the automatic
chainloading is something specific to us.
Change-Id: I0498effc5b948f0b6f5e223d0454a15a0cbb503a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
As per vcpkg documentation, this is a tweak that allows respecting the
vcpkg default target triplet environment variable, which simplifies the
command line slightly.
In order to make this also work for modules other than qtbase, we're
going to need to consider the creation of a toolchain file.
Change-Id: I2573f6644d671c710fd823df83e2205dbbfe19e6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
This changes many different CMake places to mention Qt6 instead of
Qt5.
Note that some old qt5 cmake config files in corelib are probably not
needed anymore, but I still renamed and kept them for now.
Change-Id: Ie69e81540386a5af153f76c0242e18d48211bec4
Provide add_qt_gui_executable() as function in our public API that takes
care of automaticWinMain linkage. We can use this in the future to
encapsulate similarplatform-specific behavior and adjustments, such as
module generation onAndroid.
In order for the examples to see the function in Qt5CoreMacros, three more
additional fixes were required:
* Do the build_repo_end() call _before_ attempting to build the
examples, as we need the build_repo_end() to include QtPostProcess
and complete the creation of all the target config files.
Otherwise the find_package() calls in the examples see something
incomplete.
* Add more QT_NO_CREATE_TARGET guards
* Always call find_dependency on the dependencies, regardless of the
target creation mode. This way a find_package(Qt5 COMPONENTS
Widgets) will still load Qt5CoreMacros.
Change-Id: I03ce856e2f4312a050fe8043b8331cbe8a6c93e6
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make sure to prepend our own paths instead of appending, as we'd like
cmake to search there first.
Change-Id: I0caea3a2654fbb07d5843f255cc35fca8892e19d
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
for modules, plugins and tools only (i.e. no tests nor examples)
this mimics the qmake behavior
default value is developer_build
Comes with some fixes in qmake since it seems in the qmake built it was
not having Werror, now does because we built it with add_qt_tool
Change-Id: I6f3237f25a6fedefa958644929e90f13837a12df
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In particular, Qt targets extended with other qt targets
(eg. Qt::VulkanSupport or Qt::LinuxAccessibilitySupport)
after the first add_qt_module were not taken into account when generating
Depends files.
Note that this patch updates the minimum required version
to CMake 3.15
Change-Id: I747deedd4d59e385876bc1a834ef9bdb6078911b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Toolchain files from sysroots (such as Yocto or Android) typically set
the CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY to ensure that no external
packages are accidentally found. Similar to how we discover the Qt tools
packages for cross-compiling, we need to temporarily change the mode to
BOTH to locate our build internals.
Change-Id: Ib4374ee4a974379213218b7ec430637857ed02e7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To implement this, create a new Qt5BuildInternals package.
All child Qt modules like qtsvg should use
find_package(Qt5BuildInternals) or
find_package(Qt5 COMPONENTS BuildInternals) in the their
top level CMakeLists.txt.
This will make the qt_build_repo() macros available.
For qtbase we slightly cheat, and specify a CMAKE_PREFIX_PATH
pointing to the source folder that contains the BuildInternals
package.
For the other modules we actually use a configured and installed
package Config file.
This change moves variables that used to be written into the
QtCore Config file into the BuildInternals package. This way
things that are relevant only for building additional Qt modules
does not pollute the QtCore package.
Task-number: QTBUG-75580
Change-Id: I5479adff2f7903c9c2862d28c05c7f485ce3e4eb
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The dev->wip/cmake merge is done already.
Change-Id: Ia6b17ac633cd2bcd1e9f6e96a0a0bf33042ed63b
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
Apparently calling set_package_properties with TYPE REQUIRED and
then calling feature_summary with FATAL_ON_MISSING_REQUIRED_PACKAGES
and PACKAGES_NOT_FOUND is not enough to make CMake fail when not
finding a required package.
You have to explicitly set REQUIRED_PACKAGES_NOT_FOUND to force
feature_summary to fail when a package is not found.
Do this, and also explicitly add the rest of the NOT FOUND cases,
to get a slightly clearer overview what kind of packages were not
found.
Task-number: QTBUG-74133
Change-Id: Id21af13dafafe0a458cff479e8abbc6aa7e6a3f7
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
We must instruct cmake that we're interested in providing input files
for the assembler directly and the file name needs to be correct, too :)
Change-Id: I7cccb6ac66d28261ee71869991b14ac20c63050e
Reviewed-by: Liang Qi <liang.qi@qt.io>
It appears that the latest cmake provides 3.14 as a proper version.
Change-Id: Ib0f0a1bbdd11e2129f25618b412015a2456aaba1
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
* Only import features once
* Move Core specific code into its CMakeLists.txt file
* More consistently use target names like "Core" to
refer to "Qt modules". We tend to require either "Core"
or "QtCore" in places, which I find confusing.
Change-Id: Id54161bc5468412750cb9eb7eeb15de3812e8a09
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Use "cmake -DBUILD_CMAKE_TESTING=ON" to enable running cmake build system
tests with ctest.
Change-Id: I0a32e2d1771c9bbb0df013d0d955a9b58b1d4b79
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@qt.io>
