This allows doing debug_and_release builds with Ninja on all
platforms.
The "Ninja Multi-Config generator" is available starting with CMake
3.17.
Desired configurations can be set via CMAKE_CONFIGURATION_TYPES.
Possible values: "Release, Debug, RelWithDebInfo, MinRelSize".
For example -DCMAKE_CONFIGURATION_TYPES="Release;Debug".
The first configuration is the 'default' configuration which is
built when calling ninja with no arguments.
To build all targets of a certain configuration use "ninja all:Release"
or "ninja all:Debug".
To build all targets in all configurations use "ninja all:all".
Note that the first configuration influences which configuration of
tools will be used when building the libraries for all configurations.
In simple terms, when configured with
-DCMAKE_CONFIGURATION_TYPES="Release;Debug" the release version of moc
is used by AUTOMOC.
When configured with -DCMAKE_CONFIGURATION_TYPES="Debug;Release"
the debug version of moc is used by AUTOMOC.
Framework builds and Ninja Multi-Config don't currently work together
due to multiple bugs in CMake, which ends up generating an invalid ninja
file with duplicate rules. There are also issues with placement of the
debug artifacts.
This will be handled in a follow up patch after CMake is fixed.
Task-number: QTBUG-76899
Change-Id: If224adc0b71b7d1d6606738101536146aa866cd7
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Tested locally with the following configurations:
- iOS device builds (arm64)
- iOS simulator builds (x86_64)
- iOS simulator_and_device builds (fat arm64 and x86_64 archives)
All iOS builds currently require a custom vcpkg fork which contains
fixes for building the required 3rd party libraries.
qtsvg, qtdeclarative, qtgraphicaleffects and qtquickcontrols2
have also been tested to build successfully.
simulator_and_device builds are also supported, but require an umerged
patch in upstream CMake as well as further patches to vcpkg.
Task-number: QTBUG-75576
Change-Id: Icd29913fbbd52a60e07ea5253fd9c7af7f8ce44c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Rename internal APIs like extend_target to qt_extend_target.
Prefix apis with qt_ where required.
Keep old names for compatibility until all their usages are removed.
Change-Id: I9a13515a01857257a4c5be3a89253749d46a4f41
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
A developer can pass either -DQT_NO_MAKE_TESTS=ON or
-DQT_NO_MAKE_EXAMPLES=ON to exclude tests or examples from being built
as part the default make target (when you write just make or ninja).
With ninja, tests and examples can be built separately one by one,
by typing
$ ninja tst_foo
or
$ ninja example_bar
Same can be done with the Makefile generator.
$ make tst_foo
All tests / examples can be built in one go by typing
$ ninja tests/all
or
$ ninja examples/all
With the Makefile generator unfortunately it's not as nice and is most
likely an implementation detail, but it can still be done by running
something like
$ make -f CMakeFiles/Makefile2 tests/all
or
$ make -f CMakeFiles/Makefile2 examples/all
Change-Id: I34f168b3ab41e952a21d3ace5634e25a9f41922e
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Previously repo/tests/CMakeLists.txt was a standalone project on which
CMake could be called. This was useful for Coin to be able to build
and package only tests, but was a bit troublesome because that means
having to specify the usual boilerplate like minimum CMake version,
which packages to find in every tests.pro project.
Instead of having a separate standalone project, modify the top level
project and associated CMake code to allow passing a special
QT_BUILD_STANDALONE_TESTS variable, which causes the top level project
to build only tests, and find Qt in the previously installed qt
location.
This also means that when building a repo, we generate a
${repo_name}TestsConfig.cmake file which does find_package on all the
modules that have been built as part of that repo. So that when
standalone tests bare built for that repo, the modules are
automatically found.
qt_set_up_standalone_tests_build() is modified to be a no-op because
it is not needed anymore. Its usage should be removed from all the
other repos, and then removed from qtbase.
Non-adjusted tests/CMakeLists.txt projects in other repositories
should still be buildable with the current code, until they are updated
to the new format.
Adjust the Coin build instructions to build the standalone tests in a
separate directory.
Adjust pro2cmake to generate new structure for the tests/tests.pro
projects.
Adjust the qtbase tests project.
Fixes: QTBUG-79239
Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Convert benchmark executables to add_qt_benchmark().
Currently add_qt_benchmark just calls add_qt_executable() and
ensures that it they build under CMAKE_CURRENT_BUILD_DIR and do not
install.
Add QT_BUILD_BENCHMARKS option to enable/disable building of benchmarks.
Change-Id: Id0bc676698d21d50048d97d9abef51d92ccb6638
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
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
QT_SOURCE_TREE is a variable that is set in qtbase/.qmake.conf.
In qtbase, it's used throughout various
projects to find cpp sources when building standalone tests (among
other things).
Everything works fine with qmake, because even if qmake is invoked
on the tests subfolder, qmake searches up the source directory tree
until it finds a .qmake.conf file, and uses that.
When building qttools with qmake, the qdoc project expects
to have a QT_SOURCE_TREE value, but it's not actually set in the
qttools/.qmake.conf file, so the generated include paths that use
that value are incorrect. Curiously the build still succeeds.
Now in CMake land we replaced QT_SOURCE_TREE with
CMAKE_SOURCE_DIR, but that does not work properly when doing a
standalone tests build, because the project in that case is the
tests one, and not the qtbase one, so configuration fails in a
developer build when trying to configure some private tests.
So far I've found that only qtbase actively uses this value.
A temporary fix is to save the qtbase source directory into a
QT_SOURCE_TREE variable inside the generated
BuildInternalsExtra.cmake file.
The pro2cmake script is changed to handle presence of QT_SOURCE_TREE
in a qrc file path. This is handled by finding the location of a
.qmake.conf file starting from the project file absolute path.
This is needed to stop the script from crashing when handling
the mimedatabase test projects for example.
The change also regenerates the relevant failing test projects, and
thus standalone tests (when doing developer builds aka private_tests
enabled) now configure and build successfully.
Change-Id: I15adc6f4ab6e3056c43ed850196204e2229c4d98
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
QT_WILL_INSTALL was previously always set to ON when doing a
qtdeclarative build, because
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT evaluated to false due to
always having to set CMAKE_INSTALL_PREFIX to point to the qtbase build
directory.
Instead of recomputing the value of QT_WILL_INSTALL, compute it once
while configuring qtbase, and add it to the generated
QtBuildInternalsExtra.cmake file, so it propagates to all other repos
that will be built.
Change-Id: If8bf63e7501b5758fe7aa0f799cb0746704f4811
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Just like with qmake, separate the two "features".
Change-Id: Idf2a796c7c4aaa740c471688b2221d7041fed643
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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
Generate the android deployment settings json for android apk
targets. QtPlatformAndroid is now also deployed as a public
build dependency of QtCore. Some minor refactoring has been
performed to the naming of variables and functions to
better match the public facing apis.
Extra settings for the file can be configured using the
following target properties:
set_target_properties(Core
PROPERTIES QT_ANDROID_DEPLOYMENT_DEPENDENCIES "foo;bar"
QT_ANDROID_EXTRA_LIBS "foo;bar"
QT_ANDROID_EXTRA_PLUGINS "foo;bar"
QT_ANDROID_PACKAGE_SOURCE_DIR "/foo/bar/"
)
The file is generated using the function
qt_android_generate_depoyment_settings().
We need to install the android template files and jar
files during the android build as the androiddeployqt tool
wont work if parts of it are split between the host
install and the android install.
Added QT_BUILD_QT variable to check whether we are building
Qt from source.
Finally, we also force the stdlib to shared via cmake
configuration with -DANDROID_STL="c++_shared"
Change-Id: I063c47e11749d56ba4c6f02101dbcc09e1b9fe87
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Move the include of the platform from QtPlatformSupport to QtSetup. This
no longer causes compile tests to fail since they expect explicit
include paths instead of using CMAKE_MODULE_PATH.
Change-Id: I9d3bed7845104d84422afb5a976ec14b111d259d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Mimic the behavior in the qmake build system, and by default build
tests for developer-build, and not build it for a normal build.
To do this, we define BUILD_TESTING with the right default before
including CTest, which does otherwise define the option itself.
Change-Id: Ifa1b1156477919abc1e916ccd9e1e0a74e969ee6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For developer builds, enable the compile commands database by default.
This allows Qt developers to use tools that utilize these (such as
clang-tidy, etc.) without any extra setup.
Change-Id: I79d70ef7dbe7c59864e93593c75f9ff6cd67c2ce
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
Once qtbase is built and installed, save the CMAKE_INSTALL_PREFIX
that was used during the build, and set it when a consumer calls
find_package(Qt5BuildInternals).
This fixes a bug where syncqt can not be found when building qtsvg,
while the developer specifies CMAKE_PREFIX_PATH to find the Qt packages,
but does not set the CMAKE_INSTALL_PREFIX.
Task-number: QTBUG-75544
Change-Id: I03fd23ba418af5115105610f3f9ed92664562945
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
A non-prefix build is a build where you don't have to run
make install.
To do a non-prefix build, pass -DFEATURE_developer_build=ON when
invoking CMake on qtbase. Note that this of course also enables
developer build features (private tests, etc).
When doing a non-prefix build, the CMAKE_INSTALL_PREFIX cache variable
will point to the qtbase build directory.
Tests can be run without installing Qt (QPA plugins are picked up from
the build dir).
This patch stops installation of any files by forcing the
make "install" target be a no-op.
When invoking cmake on the qtsvg module (or any other module),
the CMAKE_INSTALL_PREFIX variable should be set to the qtbase build
directory.
The developer-build feature is propagated via the QtCore Config file,
so that when building other modules, you don't have to specify it
on the command line again.
As a result of the change, all libraries, plugins, tools, include dirs,
CMake Config files, CMake Targets files, Macro files, etc,
will be placed in the qtbase build directory, mimicking the file layout
of an installed Qt file layout.
Only examples and tests are kept in the separate module build
directories, which is equivalent to how qmake does it.
The following global variables contain paths for the
appropriate prefix or non prefix builds:
QT_BUILD_DIR, QT_INSTALL_DIR, QT_CONFIG_BUILD_DIR,
QT_CONFIG_INSTALL_DIR. These should be used by developers
when deciding where files should be placed.
All usages of install() are replaced by qt_install(), which has some
additional logic on how to handle associationg of CMake targets to
export names.
When installing files, some consideration should be taken if
qt_copy_or_install() needs to be used instead of qt_install(),
which takes care of copying files from the source dir to the build dir
when doing non-prefix builds.
Tested with qtbase and qtsvg, developer builds, non-developer builds
and static developer builds on Windows, Linux and macOS.
Task-number: QTBUG-75581
Change-Id: I0ed27fb6467662dd24fb23aee6b95dd2c9c4061f
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
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>
This is especially important on macOS when doing a debug build,
because QPluginLoader is looking for the cocoa QPA plugin
suffixed with "_debug" when executing a test or example.
Change-Id: Ief23b3a82c567c16ab9dd30d04d1729031262d7d
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Only has warnings for now
Next to come is the support for developer-build and enabling Werror
Change-Id: I8070dc06eb439c2a03007cce975c8147ff7e1582
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Because the default "empty" CMAKE_BUILD_TYPE is a weird default
Change-Id: I5768f67aa85dce4108e421d2f4eacdfb1cb5beb0
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
Pass -DQT_USE_CCACHE=ON to enable the use of ccache. This avoids having
to set up symlinks, which is useful when cross-compiling against
different targets.
Change-Id: I023fff105baaa538730997948aa122d2678887ce
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
This is not quite the correct design yet, but makes the existing
mechanism work first.
Change-Id: Idbc6f1380adc955a772eb6e5beb6b3a5f7f686bb
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
