Pass in the QT_CMAKE_BUILD define to change the expected executable name
in the tests.
Add special cases for missing compile flags that cause the collection of
backtraces to fail otherwise.
Change-Id: I53c44f7e4c6d597f941e4dd8173b3a39a615339c
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@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
The missing commit is in wip/cmake, so it should be safe to
reactivate the plugins again.
This reverts commit f2c57e83ab.
Change-Id: I1a95dac3008674f8baf009cf5556a313cae3d8b3
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qabstractsocketengine.cpp was changed to explicitly include its header
moc file, which works with AUTOMOC, but doesn't with qmake.
The header file needs to be explicitly listed in the HEADERS variable.
Amends 2a1fc7b835.
Change-Id: I9d31288d1f1eb2310679a7e685bd7ea458a77920
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
We did some changes in the .cpp files of some tests when converting
the build system to CMake, but didn't adjust the .pro files which
caused tests to fail when doing a qmake build.
Make the required changes. Was discovered when doing a test
wip/cmake -> dev merge.
Change-Id: I407a982412cb44df592a38a4cb997968bdfe3304
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This smells like copy & paste from the boostrap lib.
Change-Id: Ibb0c392df610f02fc3bdcfc72a2d0c925e27a89e
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
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>
Use all the original non-normalized feature names, and normalize them
in CMake land rather than Python. This gives us the necessary
original name information for further usage when generating qmake
pri and prl files.
Change-Id: If9db9028dac6175b8f6971e4b91558d76b8e9296
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
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>
tests/auto/corelib/kernel/qsocketnotifier includes cpp files from
src/network, and this blows up at the linking step in a static build,
due to duplicate symbols when linking the mocs_compilation of network
and the test.
Include the moc file in the .cpp file as we usually did in other cases,
to prevent duplicate symbols.
Change-Id: I2fb15058cb4477201af7bd053407e20970a947bb
Reviewed-by: Qt CMake Build Bot
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
There is a patch in progress to add mappings for Qt3D, so reuse the old
broken Qt3D mappings, delete the duplicates.
QtOpenGLExtensions is needed, so this patch includes it.
Change-Id: I27896ee88b9e6873c8cd52d86afc330e309e1e14
Reviewed-by: Alexandru Croitor <alexandru.croitor@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
Handle conversions for QT_NO_CURSOR, QT_NO_TRANSLATION and
qtConfig(opengles.).
Change-Id: Idd930f77e78f235b7997a5083ac7faf630ed9801
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The script can now generate both old style CMake API calls
(add_qt_module), as well as new style (qt_add_module).
The first case is considered api version 1, and the second case
is version 2.
You can force which api version to use for generation using
the --api-version command line argument.
This is useful when you want to regenerate an old project
(one that hasn't switched to new style), to keep the diffs
easier to read.
When no parameter is specified, the script will auto-detect
which api version is used in the existing CMakeLists.txt file
(if it exists), and keep using that, until someone force regenerates
the project with a new api version.
Change-Id: I41e4e6ed5db94ef7220c09b46fc5f12e6613e5d2
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
