If the user turns on debug_and_release with the configure script,
FEATURE_debug_and_release will not be set, and the debug postfix won't
be set correctly.
Directly use FEATURE_debug_and_release's condition instead.
Change-Id: Ica4af3caa25f2e6712eca4659818aac2c8b95256
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Configure now translates -developer-build to INPUT_developer_build
without setting FEATURE_developer_build.
The install prefix determination code in QtSetup.cmake happens much
earlier than the feature evaluation. As the developer_build feature is
merely a switch that's supposed to be flipped by the user, we can just
translate the INPUT_developer_build value to FEATURE_developer_build in
QtSetup.cmake.
Fixes: QTBUG-88318
Change-Id: I57918232359e2e367e41b779d3f4737731dd76e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This option maps to FEATURE_reduce_exports. The feature is on by
default, except for MSVC. The reduce_exports configure test is not used
in the CMake build.
The <LANG>_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN target
properties are now explicitly initialized in the
qt_set_common_target_properties function, because we don't have access
to the feature in QtSetup.cmake where the CMAKE_<LANG>_VISIBILITY_PRESET
variables were set before.
Task-number: QTBUG-85373
Change-Id: I378453f0e0665731970016170302871e20ceb4e2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
HostInfo is used in places whenever QT_HOST_PATH is set, regardless
whether CMAKE_CROSSCOMPILING is set or not. Make sure that HostInfo
is available when QT_HOST_PATH is set.
Change-Id: I39763a61d77e97dc9c4cc3875bce4deb942f870a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
While trying to implement the 'host artifact reuse' Coin instructions
change, a bug surfaced where the qemu configurations didn't find
the host tools and instead tried to use the cross-compiled tools
while building qtbase, which failed due to not finding the
runtime linker (another unsolved issue).
Before the host artifact reuse change, the host tools were found
successfully.
The difference that caused the issue is that the target install prefix
was a direct subfolder of the host prefix.
host - /home/qt/work/qt/install
target - /home/qt/work/qt/install/target
Before the host reuse change the install prefixes were as follows
host - /home/qt/work/qt/install/host
target - /home/qt/work/qt/install/target
While looking for the Qt6CoreTools package, we temporarily set
CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH to contain first
'/home/qt/work/qt/install' and then '/home/qt/work/qt/install/target'.
CMake then reroots the CMAKE_PREFIX_PATH values onto values in
CMAKE_FIND_ROOT_PATH, making an MxN list of prefixes to search.
Rerooting essentially means concatenating 2 paths, unless the
considered prefix is a subfolder of the root path.
What happened was that the first considered value was
'/home/qt/work/qt/install/home/qt/work/qt/install', a non-existent
location that gets discarded.
The second considered value was '/home/qt/work/qt/install/target.
The second value is the result of seeing that
'/home/qt/work/qt/install/target' is a subfolder of
'/home/qt/work/qt/install' and thus the root path is stripped.
All of this is done in cmFindPackageCommand::FindConfig() ->
cmFindCommon::RerootPaths.
The behavior above caused the target tools be found instead of the
host ones.
Before the host reuse change, both of the initial constructed prefixes
were discared due to them not existing, e.g.
'/home/qt/work/qt/install/target/home/qt/work/qt/install/target'
and '/home/qt/work/qt/install/host/home/qt/work/qt/install/host'
One of the later prefixes combined CMAKE_FIND_ROOT_PATH ==
'/home/qt/work/qt/install/host' + CMAKE_PREFIX_PATH == '/' resulting
in '/home/qt/work/qt/install/host/' and this accidentally found the
host tools package.
We actually stumbled upon this issue a while ago when implementing Qt
5.14 Android CMake support in 52c799ed44
That commit message mentions the fix is to add a "lib/cmake"
suffix to the PATHS option of find_package().
This would cause the subfolder => strip root behavior mentioned
above.
So finally the fix.
First, make sure not to append QT_HOST_PATH in the toolchain file,
there shouldn't be any need to do that, give that we temporarily set
it when looking for Tools packages.
Second, recreate the subdir scenario in the Qt toolchain file by
setting CMAKE_FIND_ROOT_PATH to the current (relocated) install
prefix as usual, but also setting CMAKE_PREFIX_PATH to a new value
poining to the CMake directory.
Aka '/home/alex/qt' and '/home/alex/qt/lib/cmake'.
Third, when a QT_HOST_PATH is given, save 2 paths in the generated Qt
toolchain: QT_HOST_PATH and QT_HOST_PATH_CMAKE_DIR. There are the host
equivalents of the target ones above. Use these values when looking
for host tools in Qt6CoreModuleDependencies.cmake, again facilitaing
the subdir behavior.
Note these are currently absolute paths and are not relocatable.
We'll have to figure out if it's even possible to make the host path
relocatable.
Finally as a cleanup, look for the Qt6HostInfo package in QtSetup
strictly in the given QT_HOST_PATH, so CMake doesn't accidentally find
a system Qt package.
Change-Id: Iefbcfbbcedd35f1c33417ab7e9f44eaf35ff6337
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
For repositories other than qtbase the QT_STAGING_PREFIX was empty,
because it was only determined in qtbase.
Also, we save the CMAKE_STAGING_PREFIX in the Qt6BuildInternals package
and set this variable if it's not explicitly set by the user.
As with CMAKE_INSTALL_PREFIX this behavior can be prevented by defining
QT_BUILD_INTERNALS_NO_FORCE_SET_STAGING_PREFIX=ON.
Change-Id: I73100abbef24f5d3fb8f82029d0374176edc8048
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the cache variable QT_STAGING_PREFIX that is the same as
CMAKE_STAGING_PREFIX - if it's set, or CMAKE_INSTALL_PREFIX otherwise.
Use the variable in the places where we check for the emptiness of
CMAKE_STAGING_PREFIX to use CMAKE_INSTALL_PREFIX.
Change-Id: I372d57dfa41818c1965b824c59ab3cac80b38f60
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QT_WILL_INSTALL was set to ON, because an incorrect comparison was
done.
Amends 062318feb2
Change-Id: I201aa2a183563ce05077c36ac2ba3bd61cc827c0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
It wasn't possible to create a cross, non-prefix build with
CMAKE_INSTALL_PREFIX set to something else but the qtbase build dir
and CMAKE_STAGING_PREFIX set to the qtbase build dir.
This would be equivalent to
configure -prefix /usr \
-extprefix ~/my/qtbase/build/dir
Fix this by comparing the qtbase build dir against
CMAKE_STAGING_PREFIX if it is set. We also have to adjust the
QT_BUILD_DIR variable in a similar way.
Change-Id: Iaba5cf0f6954ae4b15d8af1fc62634f5d7f68835
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When cross-compiling, we now create a target_qt.conf file that's to be
used with the host Qt's qmake. With "qmake -qtconf .../target_qt.conf"
projects can be cross-built against the cross-built Qt.
We also create wrapper scripts for the host qmake to save the user from
passing the -qtconf argument.
Fixes: QTBUG-82581
Change-Id: Ib5866e7e820369efea9eb3171e3e3e3ca5c0c3c1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Otherwise the Objective-C++ sources will be built with the default
compiler visibility (visible), and then linked with moc-generated
C++ sources that have the Qt overridden hidden visibility, resulting
in linker warnings such as:
ld: warning: direct access in function 'X' from file 'moc_foo.cpp.o'
to global weak symbol 'Y' from file 'bar.mm.o' means the weak symbol
cannot be overridden at runtime. This was likely caused by different
translation units being compiled with different visibility setting
Change-Id: I22e15e7e181a74de8c0a22c73d06e600e582d7fd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The change fixes the labels to show up correctly in the configure
summary.
It also allows enabling the sanitizer via the feature flags, e.g.
-DFEATURE_sanitize_address=ON.
Finally the qtbase sanitizer option is saved in QtBuildInternalsExtra
so that repos built after qtbase have the same sanitizer options
enabled.
Change-Id: Ic9d9e3ce3c7ebbc244ced2e6d163d1ac8ee06b12
Fixes: QTBUG-84721
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
To be in line with the qmake build we drop the "d" suffix for MinGW
debug libraries unless the debug_and_release feature is enabled.
Task-number: QTBUG-84781
Change-Id: I1b83492bff561d3d7647dde467931ec3866ae940
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Users / developers usually configure a single example. The CI
can still continue to explicitly configure and build all examples.
Task-number: QTBUG-84471
Change-Id: I1c9ac857e7ad0e5602037265194f0a6742386b51
Reviewed-by: Joerg Bornemann <joerg.bornemann@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>
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>
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>
Qt uses the qtNomakeTools() function to mark a directory which will
not be built as part of the default target. This is especially
important when cross-compiling (to iOS for example) because the build
process might fail.
The condition for not building these "GUI tool sub-directory projects"
is the absence of the "tools" value in qmake's QT_BUILD_PARTS
variable.
Introduce a QT_NO_MAKE_TOOLS CMake variable. If the value is true,
it's equivalent to "tools" not being present in QT_BUILD_PARTS.
Introduce qt_exclude_tool_directories_from_default_target().
It's the qmake counter part to qtNomakeTools().
Teach pro2cmake to generate it where appropriate.
Change-Id: If2e5958d91847ab139af0e452608510286e73fa0
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Teaches configurejson2cmake about summaries / reports, so things
like enabled features, configure sections, notes, etc.
Add relevant CMake API for adding summary sections and entries,
as well as configure reports. The commands record the passed data,
and the data is later evaluated when the summary needs to be printed.
This is needed, to ensure that all features are evaluated by the
time the summary is printed.
Some report and summary entries are not generated if they mention a
feature that is explicitly exclduded by configurejson2cmake's feature
mapping dictionary. This is to prevent CMake from failing at configure
time when trying to evaluate an unknown feature. We should re-enable
these in the future.
A few custom report types are skipped by configurejson2cmake (like
values of qmake CONFIG or buildParts).
These will have to be addressed a case-by-case basis if still needed.
Change-Id: I95d74ce34734d347681905f15a781f64b5bd5edc
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Depends on a new bleeding edge feature in as-of-yet unreleased
CMake 3.18, that allows building macOS frameworks using the
Ninja Multi-Config generator targeting more than
one configuration.
It uses the new CMAKE_FRAMEWORK_MULTI_CONFIG_POSTFIX_DEBUG
property which tells CMake to create properly named debug artifacts
in the Multi-Config ninja file.
Without it, both debug and release artifacts would have the same
location (no _debug) postfix, so it would be unclear which file
ends up being compiled as last (the debug or release variant).
Change-Id: I3e10832551731a18317da8f9667d96cec3dc3028
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This feature is read-only. It's controlled by the multi-config feature
of CMake. It mainly exists for the qmake support.
Change-Id: I322459598fe92568eda4d42319ded444537e95d4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
