Otherwise CMake sets an up an empty default value itself, and then
the value in QtBuildInternalsExtra does not end up being used, and
then QtSetup ends up setting a Debug value.
Amends 34a112e383
Change-Id: If97a1d8c19ad5e7f690283997ff80dd9588cd521
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Due to generator expression it is impossible to recursively evaluate the
link dependencies of a target. This is required by QtDeclarative's
qmltyperegistrar.
To overcome this we generate a ${target}_metatypes_dep.txt file which
contain lines with the following pattern:
${PATH_TO_METATYPES.json}=${PATH_TO_METATYPES_DEP.txt}
This can be used to recursively evaluate the dependencies at run time.
Change-Id: Ia4cee0632c16ba9631e0289db906fe9d320844a3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
Rather than pass the build type in the wrapper, make sure the build
type is a cache var, so it gets picked up when building other repos.
This reverts commit f72ca4cf85.
Change-Id: I5d91ab66249b6c40c5e548b0eec0e467ba0f2ebc
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
If the OUTPUT_NAME of a plugin is the same as the CMake target name,
don't try to create a custom target with the same name. That will
cause configuration errors due to duplicate targets.
Amends f67d8ae2d4
Change-Id: Iaea7c68e22dbc1e345ba10950c312618abba4c21
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
In Qt 5, qmake generates CMake Config files which expose the plugins
as imported libraries. The name of these libraries are derived from
the plugin class name. So QCocoaIntegrationPlugin, and not qcocoa.
To keep compatibility between Qt5 and Qt6 CMake target names,
the pro2cmake script should generate plugin target names based on the
plugin class names.
To avoid passing the same name in qt_add_plugin (target and CLASS_NAME),
derive the class name from the target if the class name is
not explicitly specified.
Also add a new OUTPUT_NAME parameter which is used to change the
final file name of the plugin, so that it's compatible with Qt5.
For example to generate a qcocoa.dylib file, instead of
QCocoaIntegrationPlugin.dylib file.
The same OUTPUT_NAME value will be used for generation of plugin .prl
files for qmake consumption.
Change-Id: I4d53e680d7beb62befecd359cdf6bba60a34ff0d
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@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>
This manifested in Coin when ninja tried to build qdrawhelper_sse2.cpp
before the Core framework headers were copied, resulting in a
fatal error: 'qatomic.h' file not found.
Make sure every SIMD object library has all PRIVATE dependencies of
its parent library PRIVATE dependencies (except for other SIMD object
libraries), to make sure that the framework headers are copied by the
time the SIMD source file is compiled.
Here's an example for clarification. Gui_simd_sse2's LINK_LIBRARIES
property should have all the values of Gui's LINK_LIBRARIES property
(like Qt::Core) filtering out all SIMD object library targets (
like Gui_simd_sse2, Gui_simd_sse3, etc).
Thus we make sure the SIMD object libraries are built after Gui's
dependencies are built.
Note that using INTERFACE_LINK_LIBRARIES to avoid the filtering of SIMD
targets in the generator expression would only work in shared Qt builds.
In static Qt builds where PRIVATE dependencies become PUBLIC, CMake would
insert $<LINK_ONLY:Gui_simd_foo> entries in INTERFACE_LINK_LIBRARIES
which causes CMake to be confused and fail at generation time.
Change-Id: I246c1394b9c9830c0ebd11e6621e56b992a6a1f2
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When running tests with CMake's CTest, set the environment
QT_TEST_RUNNING_IN_CTEST to 1. This can be useful to deal with tests
that do not properly work when running from CTest.
For instance, the qmake test in this patch has one test that only works
when not run from CTest.
Change-Id: I01eea9131de69c18118a9ed9f96e9296d5ea20f1
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Framework builds are enabled by default on macOS.
They are controlled via the framework feature.
Task-number: QTBUG-75751
Change-Id: I00bc64672f02bbd1672508b2b5010d202984a961
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Qt CMake Build Bot
Adds custom targets which take care of generating and installing
documentation files.
Every module has a global set of targets suffixed with the module
name in order for them to be unique when we implement super builds.
The targets are the same as the list below, but replace ${target}
with the module's name. Eg.: docs_qtbase.
For every target which has an qt_add_docs() call, we now create the
following set of custom targets:
* docs_${target}
* html_docs_${target}
* qch_docs_${target}
* prepare_docs_${target}
* generate_docs_${target}
* install_docs_${target}
* install_html_docs_${target}
* install_qch_docs_${target}
Fixes: QTBUG-75859
Change-Id: Ie84cb9a2dedbe7333d9a84f4d73383442deca477
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Change-Id: Iba5104cccdc613f7b2cf0d1454209578adaac824
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
- Mention location of the configure.cmake
- Specify the path to the conversion scripts
Change-Id: Ia6e13a1f4d2c29f2fbaf35acdd70ab16c7175d37
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We can't use qt_internal_export_modern_cmake_config_targets_file for
executables like tools, because it's not possible to use
INTERFACE_LINK_LIBRARIES with executables like you can with libraries.
We also can't create aliases to non-global imported targets.
Instead create new imported executable targets, fish out the imported
location, and assign it to the versionless targets.
Task-number: QTBUG-74137
Task-number: QTBUG-80477
Task-number: QTBUG-75984
Change-Id: I6a3c9c67ef4699c72a6c9a627c63158dfd6557f8
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Otherwise if you configured a commit that has tool A, and the switch
to a commit where tool A does not exist anymore, reconfiguration
will fail.
Change-Id: Ibb244b9630a6f4fecd27d51ce28eceff07ba8666
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This patch adds a new bootstrap tool which will read CMake's
AutoGenInfo.json and ParseCache.txt to determine what the current
list of json files is that needs to be passed to moc --collect-json
option.
Right now this is enabled for qt_add_module() with the option
GENERATE_METATYPES. pro2cmake has also been updated to detect qmake's
CONFIG += metatypes and to generate the above option for modules.
The implementation lives in Qt6CoreMacros so it can eventually be used
in the public facing apis.
The generated meta types file is saved under the target property
QT_MODULE_META_TYPES_FILE.
Change-Id: I03709c662be81dd0912d0068c23ee2507bfe4383
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Needed when building Qt Creator with CMake + Qt6 non-prefix build.
Specifically qttools's QtUiPlugin does not have any private headers,
but the non-existing include path was exported, which caused an error
when configuring Qt Creator.
Change-Id: I662bc502fe3134fba083bde273b7f63fe1470277
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before we only exported features that had outputType PUBLIC or PRIVATE
on the various "QT_ENABLED_PUBLIC_FEATURES" target properties.
Now we also export features that have output type privateConfig,
publicConfig and publicQtConfig.
The new properties names are:
- QT_QMAKE_PUBLIC_CONFIG for outputType == publicConfig
- QT_QMAKE_PRIVATE_CONFIG for outputType == privateConfig
- QT_QMAKE_PUBLIC_QT_CONFIG for outputType == publicQtConfig
These need to be exported for 2 reasons:
- other modules that need to check the config values
- in preparation for generating proper qmake .prl and .pri
information for each module
Note that the config values are now considered actual features
when doing condition evaluation. So if there exists a feature "ssse3"
with outputType privateConfig, its enabled state can be checked via
QT_FEATURE_ssse3 in consuming modules (but not in the declaring
module).
These config values are also placed in the respective
QT_ENABLED_PUBLIC_FEATURES, QT_ENABLED_PRIVATE_FEATURES properties
when exporting a target, so the properties will now contain both
features and config values.
In order to make this work, feature name normalization has to happen
at CMake time, rather than done by the python script.
This means that features like "developer-build" need to retain the
dash in the qt_feature(), qt_feature_definition() and
qt_feature_config() calls, rather than generating "developer_build"
as the script did before.
The normalization is done at CMake time. Feature conditions,
CMake code, and -DFEATURE_foo=bar options passed on the command line
should still use the underscore version, but the original name is used
for the QT_QMAKE_PUBLIC_CONFIG properties.
Note that "c++11" like features are normalized to "cxx11".
Implementation wise, the configurejson2cmake script is adjusted to
parse these new output types.
Also QtBuild and QtFeature are adjusted to save the config values
in properties, and re-export them from GlobalConfig to Core.
Task-number: QTBUG-75666
Task-number: QTBUG-78178
Change-Id: Ibd4b152e372bdf2d09ed117644f2f2ac53ec5e75
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
Inside qt_config_compile_test we use two different calls:
check_cxx_source_compiles when given code, and try_compile when
given a project.
The former caches its results, while the latter does not, which means
that the try_compile calls are re-executed on each reconfigure.
Do what check_cxx_source_compiles does internally, and don't rerun
the try_compile calls if the results were computed once.
Change-Id: I2691ff08b7bb46c3fa60bbf5ed6278731c9b8e21
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In the qtwayland repo, both WaylandClient and WaylandCompositor
packages need access to the qtwaylandscanner tool. That means
that the add_qt_tool(qtwaylandscanner) can't use the TOOLS_TARGET
argument to associate a dependency with only one of the above
modules.
Instead add_qt_tool now allows specifying a non-existent module
name for the TOOLS_TARGET argument, which can be manually
depended on by other packages.
Actually, you could specify the non-existent module before as
well, but that didn't do everything that had to be done.
This required a bit of refactoring in how the Dependencies file
for Tools packages is created. Now the file is created in
qt_export_tools.
Two new functions were also added to allow recording additional
dependencies between packages.
Also some bug fixes were done to make it all work. Specifically
the _FOUND variable generated in the Dependencies file was incorrect.
Also there are some quotes missing when appending extra package
dependencies via the QT_EXTRA_PACKAGE_DEPENDENCIES property.
Change-Id: I167efec16dff8d036e191df3572ea72764e22bc5
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Apparently we didn't have a wrap find module for it before. Add one,
and add special support to handle a Gentoo broken Config file which is
exported by an autotools build of harbuzz.
Change-Id: I83cbeb817caf2610104c16713d4eac6ab6f8c63b
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
Instead of hardcoding which platforms and which compilers support
certain linker features, do the proper probing via
check_cxx_source_compiles.
Change-Id: I676010970d8f3a8f2a8340c5d15dfcef76fe9191
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Clang doesn't have a mkspec just a win32-clang, there is
win32-clang-g++ and win32-clang-msvc.
Change-Id: Iff521e955559dfb2308e377b41e86b3f62c42e70
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In qtwayland, there were a bunch of warnings of the following type
when configuring:
"The plug-in 'f' does not belong to any Qt module".
This happened because the plugin type had underscores, and was not
sanitized when comparing a the plugin type of plugin.
Add a function to do the sanitization, and use it everywhere.
Change-Id: I728b5f1e18fa5f8876c4a57dbd4e33148cb242d5
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
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>
Some repos like qtimageformats don't generate a config file for
standalone tests because the repo creates no modules.
Amends de3a806def
Change-Id: Id42338804605a883f975feb5dd81eda5acc6e687
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Unfortunately not all repositories are marked as warning_clean
in their .qmake.conf files. For instance qtconnectivity and
qttools are not warning clean. Therefore we need to skip
warnings_are_errors flags on all targets created in that repository.
Add support for skipping the warnings are errors flags, by setting
a QT_SKIP_WARNINGS_ARE_ERRORS property on a target, and use that
within a generator expression with all the accumulated flags.
To mimic behavior of qmake, and set the property on all targets
created by add_qt_module, add_qt_plugin, etc, one simply needs
to set the QT_REPO_NOT_WARNINGS_CLEAN variable in the
repo project CMakeLists.txt.
Change-Id: Ib5a487af6601ae1519a0988a89f8083f94f92267
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This patch adds add_qt_manual_test() which is a simple wrapper around
add_qt_executable() which does not build under ${CMAKE_BUILD_DIR}/bin
or install the targets.
This could potentially be used later to tag manual tests.
Change-Id: Ic4e0a1d133009f5a858b9394347a0996cf42683f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When configuring qtx11extras on macOS, we ended up installing the
file, which made Coin think that at least one module was built,
and thus it tried to build tests as well.
Don't install the file if no modules were built, thus preventing
from trying to build tests in Coin.
Amends de3a806def
Change-Id: I920a0b40a6ded12140f251352da53b68eef6560d
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
In gui's CMakeLists.txt we have
if (NOT ANDROID)
...
add_qt_simd_part(Gui SIMD neon SOURCES ...)
...
endif()
and later
if(UNIX AND NOT ANDROID AND NOT APPLE_UIKIT AND NOT INTEGRITY AND NOT (TEST_architecture_arch STREQUAL "arm64"))
add_qt_simd_part(Gui SIMD neon
endif()
Since add_qt_simd_part internally uses an OBJECT library to compile the
sources with different flags and then link into Gui (in this case), we
may end up with an error when add_qt_simd_part is called twice for neon,
because the constructed target (Gui_simd_neon) exists already.
We can re-use an existing target though, as the SIMD features is the
same.
Change-Id: I7a21c6e66b47e918a53fa3b1a7db9e053ecc8d87
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Every time the qtbase project was reconfigured, the list of
config tests results was appended to a cache variable which was
never reset, resulting in multiple copies of the same values
being written to QtBuildInternalsExtra.cmake.
Make sure to clean the cache variable before appending to it.
Also change the variable to be all upper-case, to be consistent
with other cache variables.
Change-Id: Ic12046730a080595e19377981a726bc330641dc1
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>
When a _nolink target is exported, instead of getting the original
namespace prefix, it gets the Qt6 prefix
(OpenSSL::OpenSSL_nolink -> Qt6::OpenSSL_nolink).
There is some special case code in Network autotests which tries
to access the former target name, which doesn't exist when building
standalone tests.
Make sure to create a Qt6:: library alias for _nolink targets during a
build (so before the library is exported), and change the Network
autotests project to use this Qt6:: namespaced library, which will
ensure it is found both in a standalone tests build and in a regular
Qt build.
Also make sure to actually call find_package to find the OpenSSL
library when building standalone tests, otherwise configuration will
fail.
Change-Id: I3da5b958e72e745a50380f8ab1644459a7c6b005
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Don't call qt_android_dependencies for interface libraries.
Also make sure not to set properties which don't start with
INTERFACE_ prefix.
Change-Id: I0afdffd34c9aebe0d7ac4731b57dd4d505f84570
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
It only makes sense for non-interface libraries.
Change-Id: I80ac942ed546a6ac866e827aa2026e4e6ac897b2
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
The reason is that interface libraries have to have properties
prefixed with INTERFACE_ and more importantly we don't set the
property for interface libraries at the moment.
Amends d1542e8a73.
Change-Id: I86bf99995278b9086fa0e3815e10d5d54d9ea4dc
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
Replace condition x86 to i386 to match other platforms.
Regenerate src/gui/CMakeLists.txt
Disable SSE4 on android x86 to match qmake.
Change-Id: Ic0d330206f2d70a79d72553aa3ff0f91ff58119c
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
The last set would override the variable instead of appending to it,
thus QT_DISABLE_DEPRECATED_BEFORE was never set.
Change-Id: I173b91704a855fcda1f2b86172d318e3953466db
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
If we do not encounter the load(qt_plugin) statement in the .pro file
but we do see the entry CONFIG+=plugin, treat the target as a regular
CMake library instead of treating it as a qt_plugin by default.
Change-Id: I67ad5c865a1a5ab691a6b0d86c2db4b686aa04dd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This patch converts all add_executable calls when building for Android
to a module library and replaces the call to add_test() to use
the android testrunner binary.
Change-Id: I10ba5919217cdc93cc2cbbb7d13ad9d10fc5ac1a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
e1fd607493 in qtbase removed the
qml1 imports enum from qlibraryinfo.cpp, qconfig.cpp, etc.
With the recent merge from dev, this was not adjusted in
qt_generate_qconfig_cpp, and thus we generated one too many strings
in qconfig.cpp, which resulted in
QLibraryInfo::location(QLibraryInfo::Qml2ImportsPath) returning
"imports" instead of "qml" subfolder, thus causing all qml modules
not being found.
Fix this by removing the extra qconfig.cpp entry, and all other
references to the location.
Change-Id: I128f667281138e2e0ef0fe1ced4af0405c532fef
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This patch adds two custom targets to generate android apks. The
targets are named ${TARGET}_prepare_apk_dir and ${TARGET}_make_apk. The
first one insures the binary is copied to the right location and the
latter invokes androiddeployqt on the apk directory.
Change-Id: I8152cef387b50ec03ee2bfd92b56910a6f22754c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use STRING type for install locations as we use them relative to the
CMAKE_INSTALL_PREFIX.
PATH type will get expanded to absolute paths by newer CMake versions,
so that breaks our logic.
Change-Id: I36be1f0378c4fb07ad8db0051d540f9d243000be
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Write out a file with some JSON data to describe a module.
This file contains information on how that module has been built.
Change-Id: I8a604692663cbb7b76b96b97124130e30b822e4b
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Allow plugins to be built with undefined symbols when
ALLOW_UNDEFINED_SYMBOLS is specified.
Change-Id: I6bc809e3e5257302157bf8484f850d8319674a4a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Rename the builtin test data resource name to something more unique as
there are name clashes when building tests which also add a resource
named 'testdata'.
Change-Id: Icc1bbff3134e1dbc6ea4f6a87a1715b936c723cc
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Add support to pro2cmake to convert java code for android.
Add support to override API_LEVEL for the Android sdk jar file. If the
sdk is not found, we'll default to the one located by QT_ANDROID_JAR.
Change-Id: If0b746dc7f9148ac43e6592a4a4dd23d46bbd4cd
Reviewed-by: Simon Hausmann <simon.hausmann@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>
We cannot use a generator expression in an if statement, it does not
work. Instead, we could inspect the CMAKE_C/CXX_COMPILE_FEATURES list,
but unfortunately that's not reliable. For example it detects that ICPC
supports C++17 when in fact that depends on the installed libstdc++.
Therefore this patch revives our own configure tests.
Change-Id: Ic3bc5762fbe81837722523e3881ac16e84628519
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Latest CMake will try to compile the given precompiled headers
as C files, due to enabling the C language in the project + also
having c files.
Make sure to wrap the precompiled headers in a CXX language only
generator expression.
For details, see https://gitlab.kitware.com/cmake/cmake/issues/19839
Change-Id: Ib3508ad920092455c300b1a566ba6152bab032db
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
In the plugin test in QtBase we have a scenario where we have target
binaries that are inputs to add_qt_resource(). If we do not remove these
files from the dependency list for add_custom_command() cmake will
fail to generate the build files.
If we mark them as generated source files, we'd have to add a special
rule to generate them. Furthermore, using $<TARGET_FILE:...> does not
work due processing done by add_qt_resource.
To bypass this we check whether the property is set and instead of
adding the file to the dependency list we add the target referenced
in that property. RCC will still work as expected but will fail if the
files aren't present.
Change-Id: I16855a54f5606d6fe27ab1347ed7ff4f40392c98
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
OUTPUT_DIRECTORY by itself is not a valid cmake target property.
Change-Id: Ic3a2a81b8b982ad7ccf0551000a157f9a4d3ef22
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Note the following bigger things that had to be done:
Handle GSS library / feature with a new custom find module.
Implement rudimentary support for relocatability (does not currently
handle extprefix).
Change-Id: Ic6cd27dda7ebca9829f51cb42ea76fff6d1767ef
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
If a module is marked as NO_MODULE_HEADERS, we shouldn't
try to include the non-existing include directory which is
usually generated by syncqt.
Note it seems that NO_SYNC_QT and NO_MODULE_HEADERS seems
to converge, so it might make sense to merge them in the future.
Change-Id: Iab4e2907ed68776632337b37496b015535da8784
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Generated plugin CMake files should always try to call
find_dependency, especially in static builds.
pkg_check_modules sets a cache value for foo_FOUND instead of
a directory scope foo_FOUND, which means that find_dependency
will not be called in another scope, and thus fail to create
needed imported targets.
Note this makes the code be the same as in
ModuleDependencies.cmake.in.
Change-Id: I0b58b038afcb72cb27d0b433371bc9cb5e4bfec9
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Add condition replacements for the android ABIs.
Add a replacement for QT_ARCH to ANDROID_ABI, since QT_ARCH is only used
with the android build for now.
Change-Id: I553d7910546de32236f723ec2e9a05a18da76130
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
extend_target() does not handle the OUTPUT_DIRECTORY argument, so we
must handle it ourselves.
Change-Id: I31880a516ae185f3255b2a51f41d61ee6b1d9838
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's probably best to make it follow the usual calling convention that
the associated (consuming) target is the first parameter of the
function. So first this change accepts both formats.
Change-Id: I1f20706b23d5e819e0eb689eecedb3afb49df3b7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Provide a SKIP_INSTALL argument to add_qt_plugin for test cases with
plugins lacking install information.
Change-Id: Iddb3843fab1790d69d64686530a46057a2ff0477
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add add_cmake_library to allow us to create normal cmake targets using
all the information we have collected via the conversion script.
This function is only meant for tests. For an example,
see tests/auto/corelib/plugin/qpluginloader/lib/lib.pro.
Change-Id: I738cb8ac241b8da1a1da3ef957c24dc7a754d43f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When we run into a plugin that does not have a type and is not a
qml plugin, we try to see if we can find the target installation path
and provide INSTALL_DIRECTORY AND ARCHIVE_INSTALL_DIRECTORY to the
add_qt_plugin call.
We run into this frequently with the unit tests.
This patch also changes add_qt_plugin() to use the value provided in
INSTALL_DIRECTORY for ARCHIVE_INSTALL_DIRECTORY if no value is provided
for the latter.
Change-Id: I61278904a4d2d72308079cd362bd085b4e2f540c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
QtPlugins.cmake.in uses file(GENERATE) and target_sources() to
propagate the generated cpp files which contain plugin initialization
code to their consuming targets.
Unfortunately due to a bug in CMake, if the file is generated in a
different scope than the consuming target, the CMake generation
step will fail saying that the source file can not be found.
See https://gitlab.kitware.com/cmake/cmake/issues/18399 for details.
In the case of qtdeclarative, find_package(Qt6) is called at the top
level scope (this is when the file gets generated),
but the targets are created in subdirectory scopes, and the GENERATED
source file property is not propagated across scropes.
Circumvent the issue by instead using file(WRITE) and configure_file()
which create the file at configure time rather than generate time.
This will pollute the current binary directory with some more files,
but at least successfully fixes the build.
Change-Id: I3ab3b12dcbf6a9d0ab9ee87173e4a1952325b37b
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
Some work was needed to make the plug-in types,
and which plug-ins are available for each type
in client code.
Change-Id: Ib71feca31069deca3d3f54c8613054f5f8ae410c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
Update add_qml_module() to use the new INSTALL_QML_FILES argument from
qt6_add_qml_module().
This patch also updates pro2cmake.py to remove the QT_QML_SOURCE_INSTALL
property from qml files.
Change-Id: I6623b2de76bb55bd6750e48f7d45c53ca536b391
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Update to match latest changes to QtDeclarative.
Change-Id: Ie455c0418e95c288149b4b1a29b065a8876e8b7e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The framework is needed for qtconnectivity.
Change-Id: I6a502564fb5543ca94ba5ae458a544286e34564c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
Sometimes when writing a qt_find_package and configuring a project,
you might get the following error from CMake:
CMake Error at QtBuild.cmake (set_property)
Attempt to promote imported target "WrapFreetype::WrapFreetype" to
global scope (by setting IMPORTED_GLOBAL) which is not built in this
directory.
This means that another find_package call, found WrapFreetype
in another directory scope other than the current one, and thus the
found target cat not be made global. Sometimes that implies that the
qt_find_package might not be needed if WrapFreeType will always be
found via a transitive depdendency.
By setting QT_DEBUG_QT_FIND_PACKAGE=1 on the command line, you can
make qt_find_package skip all of its behavior if the package was
already found and the provided targets were also found.
Unfortunately this behavior can not be made the default, because there
is no way to find out in what scope the package was found, and if it's
legal to make the targets global. At least I haven't found a way to do
that yet.
Thus the opt-in QT_DEBUG_QT_FIND_PACKAGE is a means to help with
debugging such cases.
Change-Id: I04242ed0f2fd0a75bc199386d28a1a0bd92da41a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
During a static build we need to use the find modules
in 3rdparty/extra-cmake-modules/find-modules when generating a
ModuleDependencies file, so that the generated find_dependency()
calls succeed. This means that the files have to be shipped with
Qt6 package, making them pseudo public API.
There is also a need to use these files when building QtWayland.
Instead of setting / unsetting CMAKE_MODULE_PATH only in module
and plugin Dependencies cmake files, just set them once when finding
Qt6.
This will allow QtWayland and QtX11Extras to easily find the required
third party packages, without having to hardcode the paths in multiple
repos.
Change-Id: I750d0421a269e5632afa1bb62498c2501d73cdb1
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
At least on Ubuntu the name of the pkg config package
is libsystemd and not systemd.
This fixes libsystemd showing up as not found in the feature
summary.
Change-Id: I099a253026ca8096b9e2f348a5f35209d44acc6c
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
Reviewed-by: Qt CMake Build Bot
If the target exists or the find_package() call succeeds
we still need to set _FOUND to 1.
Change-Id: Ib2267c30580082dcc177ab21708a3bc5dbde974f
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
Reviewed-by: Qt CMake Build Bot
qt_find_package usually does 2 find_package() calls, one in CONFIG
mode and one in MODULE mode.
If the CONFIG mode doesn't find a Config file, the package_DIR cache
variable is set to NOTFOUND, and this causes the FeatureSummary
at the end to show that the package was not found, even if it is
found by the next MODULE mode find_package call.
Make sure to unset the _DIR variable in case if the Config module
call fails.
This fixes XRender showing up as not found even when it's found via
the FindXRender.cmake file.
Change-Id: I6ce39dad9cbb11836ca71f735a3267070c75b444
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
Reviewed-by: Qt CMake Build Bot
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>
Allow setting feature defines to ON, YES, TRUE, Y, OFF, NO, FALSE, N and
non-negative numbers like it's possible for other defines.
We'll not allow IGNORE and NOTFOUND, because they're a bit strange in
the context of features.
Change-Id: I7f6cd6dff4c68972921b499b28916c9ad789d510
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
The set command looked like this:
set \"PATH=...\"
which was setting the environment variable \"PATH.
Removing the escaped double quotes makes it actually work.
Change-Id: I2c1d5d01b4415220512b005b75b7b67c695e33ae
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>