| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until all repos are updated to use qt_add_executable instead.
This is a minimal addition, instead of the previous
QT_NO_INTERNAL_COMPATIBILITY_FUNCTIONS approach which did not
work in all cases.
Amends c3fee0d984e59cee3ab6d069011015dd850be98f
Task-number: QTBUG-87661
Change-Id: I03bbb1451de8e54be4e075f878ed104c287aa93f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also adjust pro2cmake to use the new qt_add_executable name
instead of add_qt_gui_executable.
No compatibility functions provided this time, so we'll need to follow
through all repos and regenerate all examples.
Two reasons for not providing compaitibility functions:
1) We don't intend add_qt_gui_executable to be public API
2) A previous case with qtquickcontrols2 and qttools pointed out that
making top-level builds work with cross-compatibility API is not
simple. So just go ahead and regenerate everything.
Task-number: QTBUG-87661
Change-Id: I2f228827b786ae03bf7e1bf3908ea02a8794ed52
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Having the qrc files at configure time allows qmlimportscanner to
scan them when invoked with -qrcFiles argument.
The traceability part is done via _qt_generated_qrc_files property.
Task-number: QTBUG-85994
Change-Id: I75c252a987cd1c1f49ba73ec9d100edc73c23486
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
The use-case is relevant for other platforms as well.
Now that Qt has a module system we can also replace a lot of the
hand crafted logic for linking with simpler constructs.
Change-Id: Ib6853aaf81bfea79c31f2de741d65b4b56f23ef6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of them have a different (hopefully better) name now.
Some are marked as Technical Preview.
Some are renamed to be internal.
Marking add_qt_gui_executable as TP with the intention to un-TP it
after we rename it and change its behavior as discussed in the API
review meeting.
Additional changes to add_qt_gui_executable and qt6_add_resources have
been filed as separate tasks that will be worked on separately.
See comments on PS1 for details.
Task-number: QTBUG-86827
Change-Id: I56a84a1943b0902bb807310dc620eb381824e8dd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When configuring an example like
widgets/tools/plugandpaint/plugins/basictools outside of a Qt build,
the configuration fails because it tries to call the internal function
instead of the public one.
This was needed some time ago to facilitate moving from qt_add_plugin
to qt_internal_add_plugin, so some compatibility code was added.
But we've now migrated to qt_internal_add_plugin across most repos,
so we should remove the compatibility code to allow examples to
configure successfully.
Amends 6fbeef4c6b2323fc4b7856520c0f38f8139c9c54
Fixes: QTBUG-86858
Change-Id: Ib15f50351a8742c44d7a8be84be4e576cb48bddb
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|
|
|
|
|
| |
Task-number: QTBUG-86827
Change-Id: I9d97b53a8c85e0c488be312c8894a1d73397eb13
Reviewed-by: Simon Hausmann <hausmann@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add an abstraction over Qt::WinMain (aka qtmain.lib) and
iOS's runtime linker entry point (_qt_main_wrapper).
The Core target will now link against the Startup target on all
platforms, instead of just WinMain on Windows.
The creation and linkage interface definition of the Startup target
is done at find_package(Qt6Core) time via the private call of
_qt_internal_setup_startup_target().
This will add automatic linkage of WinMain to executables marked with
the WIN32_EXECUTABLE property on Windows.
As well as the addition of the '-Wl,-e,_qt_main_wrapper' linker flag
when linking iOS executables.
Qt users can opt out of this behavior by either setting the
QT_NO_LINK_QTMAIN property or variable. This is in line with
Qt 5 behavior.
Task-number: QTBUG-87060
Change-Id: I7d5e9f1be0e402cf8e67e6f55bfd285f9e6b04f4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|
|
|
|
| |
Change-Id: I77f2970d70ab221e5d7d5c5d389041ed1b6c49f5
Reviewed-by: Daniel Smith <Daniel.Smith@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Add some missing versionless functions.
Rename some functions that are not meant to be public API, and their
usages.
Task-number: QTBUG-86827
Change-Id: Ifb66c04cd7598d83fe80c01a92ab2d269ebaf396
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
I accidentally made the CLASS_NAME a multi-value parameter when adding
it.
Add a TYPE argument, which was likely intended to be there since it is
already used in an android branch.
Change-Id: Ic44dbbaeebc6863a984a7c2effbc00c3c2796b0b
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The logic is a bit involved in qmake.
The Qt internal qt_common.prf adds CONFIG += strict_c++ which applies
to qt modules, qt plugins, qml plugins, qt helper libs, winmain and
qt_apps, qt_tools, but NOT tests (which is important because the tests
on Windows MinGW fail to build without the GNU extensions).
Then default_post.prf checks for the strict_c++ value and either uses
the strict or non-strict C++ standard flags. default_post.prf is
loaded for all qmake projects, not just the Qt internal ones.
Now CMake doesn't provide a transitive based option to disable C++
GNU extensions with a mechanism similar to target_compile_features.
It only provides the CXX_EXTENSIONS property and it's associated
CMAKE_CXX_EXTENSIONS variable. We can't set the variable at a
directory scope, because that is too coarse grained.
So we rely on setting the property via a function in every relevant
qt_add_<target> function.
Now the naming of the function is weird.
We name the function as qt_internal_<...>, because it's not meant to be
used by Qt users.
We prepend an underscore to the name because we need to place it in
Qt6CoreMacros, so that the function can be called by
qt_add_qml_module which IS a public function.
That's because in Qt5 load(qml_plugin) was private API, but in Qt 6 +
CMake we decided to make qt_add_qml_module() as public API.
Change-Id: Id014626b087d590e25cb46843f93d0c67fc36e44
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new function is meant to be used where load(qt_app) is used.
It delegates functionality to qt_add_executable, while handling
some additional behavior via a finalization function (mostly handling
of macOS Info.plist files and icons, as well as Windows icons and
resource files)
It uses a new PlatformAppInternal interface target.
Task-number: QTBUG-85757
Change-Id: I1a2d5851b137fcd4a6323e0e06fb154f91619800
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure that the second rcc pass is executed whenever the
object file changes.
Patch provided by Hongpeng Liu <lhpzwd@163.com>
Fixes: QTBUG-85186
Pick-to: 5.15
Change-Id: I6e52ec15048ab286efd85500ca535b2b8b01c270
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit e343affd634 we're creating object libraries for Qt
resources in static libraries. Those must be reflected in the
generated .prl files for static builds of Qt.
In qt_add_resource, we now calculate the install locations of the
object files of rcc-generated C++ files and save them in the target
property QT_RCC_OBJECTS. This property is then passed to
QtFinishPrlFile to write the object file paths to the .prl file.
Change-Id: Ic383892d723d02fc91f712bc2dbcbc90babad074
Reviewed-by: Simon Hausmann <hausmann@gmail.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Otherwise when configuring a standalone example without specifying a
CMAKE_BUILD_TYPE (so it's empty), building fails because
qt6_generate_meta_types_json_file thinks it's being called with
a multi-config generator.
Change-Id: I360c7dbb19522155d8e72f98836fb663916715a0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously configuring a standalone example that had no explicit
INSTALL_DIR option for qt6_generate_meta_types_json_file would fail.
When no explicit location is specified to
qt6_generate_meta_types_json_file via INSTALL_DIR option, default
to installing into a lib/metatypes location relative to the install
prefix.
This is required for supporting calling
qt6_generate_meta_types_json_file when building standalone applications
or libraries (not part of the Qt build).
Make sure not to install the metatypes.json file for executables.
Install it only for libraries (aka modules).
Task-number: QTBUG-84403
Change-Id: Ie0dd75fca0cde71ccb4eb48030871e72d31d1725
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|
|
|
|
|
|
| |
CMake sets "lib" as default prefix for Windows-GNU platforms.
Change-Id: I49e3123c385610307c84c584a21f5f3827a6fafd
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
And enable the same default when building Qt itself (it's implicit).
Allow opting out on a target-by-target basis, by using the public
qt_disable_utf8_sources() API call.
Change-Id: Ifc19a744d57b96b1c74a6926a0c6628c2a820464
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|
|
|
|
| |
Change-Id: Ie32a32bd1cc3e5885a6699e8ea2281982527e50e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
According to [1] the DISCARDABLE attribute is for 16-bit Windows,
and it is ignored. We can drop it.
[1] https://docs.microsoft.com/en-us/windows/win32/menurc/common-resource-attributes
Change-Id: I70e5b0441a9d20f6c76c3d7a84947f8bce5c8fbd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|
|
|
|
|
|
|
|
| |
As what we did for QMake.
Amends commit 317383217baa280b7e7401a5adc4ce976320e272
Change-Id: Iab3b755193b5483362896da20a03fe2d59f37192
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I generated a rc file using VS2019 and I found that it's
using other macros.
According to [1], both of VOS_NT_WINDOWS32 and VOS__WINDOWS32 refers to
"File was designed for 32-bit Windows", although they have different
values, and 0x0L is the value of VFT2_UNKNOWN. So I think it's safe to
update them. VS2019 is using them as the default template for rc files,
after all.
[1] https://docs.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource
Change-Id: Ibaf91394668844492f1357da05b881b9d81aa15f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason the Help target doesn't get its RC file generated
when building qttools, which leads to a build failure.
We don't quite know yet why all this is happening, but a workaround
fix seems to be to use an OBJECT library instead of an INTERFACE
library to propagate the generated RC file.
Amends 657fa0462d552110e2ba14bcac46275e6066993f
Fixes: QTBUG-84155
Change-Id: I1e1c2f3b05bae2ed009020d031c6510a517c01ec
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For Ninja Multi-Config we now generate RC files in a path matching the
current config name.
We have to work around https://gitlab.kitware.com/cmake/cmake/-/issues/20682
to add the generated config-dependent RC files to the target.
But due to https://gitlab.kitware.com/cmake/cmake/-/issues/20683 the
OriginalFilename entry in the generated resource will be wrong for all
configurations but the main one. Cross fingers that this will be fixed
upstream. In the meantime: ignore the issue.
Drive-by changes:
- Fix the function comment.
- Surround the RC file name by double quotes in case there are spaces
in the path.
Fixes: QTBUG-83986
Change-Id: If2fec41fa8050b3feb92c3ce051fde1a5bad0239
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
| |
Change-Id: Idb11bd2058f2ec3f258845aea0d314430ff7c578
Reviewed-by: Simon Hausmann <hausmann@gmail.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
| |
Those library types typically do not have Windows resources with
version information.
Change-Id: I1a385c2ae4e40d5c153ac6501c5ed826eaf75655
Reviewed-by: Simon Hausmann <hausmann@gmail.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
| |
... and update handling of CLASS_NAME in qt_internal_add_plugin
Change-Id: Iec8e5f9f80df02c9ba21648535872988839f4b64
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a publicly callable qt6_add_plugin() API to create
plugins. This API is meant to cover cases such as the plugandpaint
example.
This patch also renames qt_add_plugin to qt_internal_add_plugin in order
to avoid clashes with the public API. To avoid breaking the existing
projects, a compatibility wrapper function is enabled by default unless
QT_DISABLE_QT_ADD_PLUGIN_COMPATIBILITY is specified.
Fixes: QTBUG-82961
Change-Id: If5b564a8406c90434f1bdad0b8df76d3e6626b5f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
| |
Move QT6_ADD_RESOURCE to Qt6CoreMacros in order to avoid the extra
config file step.
Change-Id: Ib445ca35c648cf344ee8795de8bdddc0f0758972
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
qt5_use_modules has been deprecated in 2013 (commit d9ea4bb144153)
and removed for the first time in 2018, but then brought back - see
discussion in https://lists.qt-project.org/pipermail/development/2018-June/032837.html .
Anyhow, I think we can finally put it to a rest in Qt 6.
Change-Id: I770f7e93406ad68535d1d90e4a3bacfb920e2d5a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When building qtdeclarative in a non-prefix configuration,
metatypes.json files were created in the source dir. This happened
because the default arg_INSTALL_DIR value is relative in
qt6_generate_meta_types_json_file, and thus a file(TOUCH) with a
relative path creats it in the source dir.
The fix is to check if it's relative during a non-prefix build,
and make it absolute (relative to the install prefix, which is the
qtbase build dir).
Change-Id: Ie9abbd5d93a64e79184d77655d8d8399e894fde5
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
|
|
|
|
|
|
|
|
|
| |
When using CMake 3.17 with any of the Ninja generators we can leverage
a dependency on the timestamp file produced by CMake's automoc to avoid
having a custom target run on every build.
Change-Id: Ia70d2730cc8296d0a43642655fe69b555cb393c0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
| |
gerate -> generate
Change-Id: I948a3bdb4f56584a9ab02f27760fec5989d528ce
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support to generate win32 resources files through CMake. The
functionality is implemented via qt6_generate_win32_rc_file() in
Qt6CoreMacros.cmake.
Currently qt_add_test(), qt_add_module() and add_qt_gui_executable()
call the above function when building on windows. The function itself
has been written as part of the public API so it can be called from
other locations if required.
Change-Id: Id5388b3bf9a2068b36780d8268306326f990778c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
tests/manual/rhi/hellominimalcrossgfxtriangle/CMakeLists.txt
Hopefully final merge from wip/cmake, and then all cmake changes
should target dev directly.
Change-Id: I29b04c9b0284e97334877c77a32ffdf887dbf95b
|
| |
| |
| |
| |
| | |
Change-Id: I0b262929f74c8da10f42d9ddbc7c119dc21619cf
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Conflicts:
examples/widgets/graphicsview/boxes/scene.h
src/corelib/Qt5CoreMacros.cmake
src/corelib/Qt6CoreMacros.cmake
src/network/ssl/qsslsocket.cpp
src/network/ssl/qsslsocket.h
src/platformsupport/fontdatabases/windows/qwindowsfontenginedirectwrite.cpp
src/testlib/CMakeLists.txt
src/testlib/.prev_CMakeLists.txt
tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp
Disabled building manual tests with CMake for now, because qmake
doesn't do it, and it confuses people.
Done-With: Alexandru Croitor <alexandru.croitor@qt.io>
Done-With: Volker Hilsheimer <volker.hilsheimer@qt.io>
Change-Id: I865ae347bd01f4e59f16d007b66d175a52f1f152
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Every metatypes.json files is now added as an INTERFACE source file to a
target. This enables us later to correctly collect all the
metatypes.json files from dependent targets. This information is also
correctly exported via export()/install().
To avoid the metatypes.json appearing in every target's source list,
the file path is wrapped in a generator expression which will only be
evaluated when the consuming target has the property
QT_CONSUMES_METATYPES set to true. At the moment this is limited to
targets which need to interact with qmltyperegistrar.
Change-Id: I0ffebcd069a923383f7ed11cde2c94ecf2fb13f3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
qt6_generate_meta_types_json_file() has been extended to allow the
generated moc_....cpp.json files to be manually specified. This now
enabled the metatype generation to be used without resorting to AUTOMOC.
Additionally, Core_qobject declaration order has been temporarily moved
as it otherwise does not produce the correct metatypes dependency file
for Core. This will be fixed in a follow up patch.
Change-Id: I3266ab3073db478458a0c1dbc8b9fbab16622a64
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
If we don't add the executable used by the custom_target and/or
custom_command to list of the command's/target's dependencies
(DEPENDS) the generated file will not update should the executable
change.
Change-Id: Idce30f3dd4f756d9e8f6848c5e16f5dd6c7c8f0a
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
| |
Change-Id: I7c2e859a83ea78c2a6cf2ad59c175c1b29a74621
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise we get generation errors due to calling GENEX_EVAL on
something that is an invalid target.
Perhaps there will be a better way once
https://gitlab.kitware.com/cmake/cmake/issues/20287 is fixed.
Change-Id: I6af9511cbb9942b9edbc3b3fc7028936308715d8
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@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
|
|
|
|
|
|
|
|
|
|
| |
Handle versionless plugin names passed to qt_import_plugins.
Task-number: QTBUG-74137
Task-number: QTBUG-80477
Change-Id: Ic7fb6e54d2822c7eb58a7874b4a1c137f0c101d9
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
|
|
|
|
|
|
|
|
|
|
|
| |
Create versionless function names, that coincide with the Qt 5 CMake
API.
Task-number: QTBUG-74137
Task-number: QTBUG-80477
Change-Id: I8559b2c8a49b23e5a89ec81603aaec54ea634d70
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>
|
|
|
|
| |
Change-Id: I31b761cfd5ea01373c60d02a5da8c33398d34739
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|