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>
There's no library to link against and the headers are in the system, so
we can create a synthetic import library after verifying the
compilation.
Change-Id: I9baa32cfe06f2f48adf066d558aa69646143efd0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
If the qml files are not listed in the qmldir file they do not need
to be written again, since it is expected that they are registered
by the c++ plugin code.
Change-Id: I624aedb182583f942bf1d1a322861c47a64b5065
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
As well as SIMD tests.
Change-Id: I43318418f90a6b9736eb89f008459c7d6adac8f9
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Fixes were upstreamed with commit
3b0bf71a72789eb2b79310b4f67602115e347f56 in extra-cmake-modules and this
brings the file in sync.
Change-Id: Ica3a29fd091afa669f29a3e9775e637566f1cb97
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
There is an issue about versionless tool target not finding
the regular targets, and that fails the configuration phase
of qtdeclarative.
Temporarily don't export the versionless targets, to get the
qt5 build going.
Change-Id: I5c7baff7f677f4a3f1f91b9e8082ba8a80f9cddd
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This is useful for providing private CMake API which is not part of
QtBase. Also, fix the setup files to be included when building
standalone tests. The old ${PROJECT_NAME}Setup.cmake file inclusion will
be removed once all usages are adjusted.
Prompted-by: Alexandru Croitor <alexandru.croitor@qt.io>
Change-Id: I5bc2bca7371660c00b0301e94d025a29b68d6975
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously you had to make sure to use DISABLE_TOOLS_EXPORT
in an add_qt_module call if the tools are built after the module,
as well as to manually call qt_export_tools after all associated
tools are built.
This was needlessly complex, especially for people that are porting
a repo with tools for the first time.
The tools package creation is now automatically done at QtPostProcess
step, so there is no need to use either DISABLE_TOOLS_EXPORT or
qt_export_tools() manually.
DISABLE_TOOLS_EXPORT is now a no-op, and will be removed once all repos
are updated not to use it.
Change-Id: I965b0d3a8a0cb908afae87b047083ed7bea9f02f
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Generate appropriate qt_config_compile_test() calls for config tests
that have CMake projects. These are protected by an if(EXISTS) check
so that configuration doesn't fail for repos where the config tests
have not been ported yet.
Adjust the qt_config_compile_test() function to use try_compile for
projects specified via new PROJECT_PATH argument.
Change-Id: I83c061e384f68688a654b782fd7a9bede282d1e3
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
To build examples as part of a non-installed Qt prefix build,
not-yet-installed Config files need to be found by find_package()
calls inside example projects.
Facilitate that by propagating the CMAKE_PREFIX_PATH and
QT_EXAMPLES_CMAKE_PREFIX_PATH paths in all relevant find_package()
calls where NO_DEFAULT_PATH is used.
Also adjust the inclusion of the QtFeature.cmake file to be relative
to the qt6 directory, rather than the current list directory.
This is needed to successfully find the file when parsing a Config
file from a non-installed build directory.
Change-Id: I36031279628f1f7741d8f4d7571484a6545227f7
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Otherwise we get errors like the following in non-gui projects:
Error evaluating generator expression:
$<TARGET_FILE:Qt6::uic>
No target "Qt6::uic"
Change-Id: I8a3a6f8ec5e5c1c3d1f73369c5739a321c64bfbb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt6_add_resources already supported the OPTIONS multi value parameter,
but only for the non-target case. Use the same parameter for the target
case.
Change-Id: Ib5fcb976ecbac244c3b11073b3cdd0c5c6366a87
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Qt CMake Build Bot
This clarifies the weird pause when configuring, right after
the HAVE_reduce_relocations test.
Change-Id: I0edcbbd085286c20c4eaea8d8e15a509ec93d85f
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Some tests are changing headers using defines inside the tests.
Let's more closely mirror what qmake does to fix this. And it will also
save quite a lot of space since most tests don't include all of
e.g. QtCore
Change-Id: I6f7e530f922418944d690bd2a1ee5f459ba755e1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
Store generated qrc, cpp and qmlcachegen file from invocations of
add_qt_resource/qt6_add_resources/qt6_process_resources under .rcc
in the target's binary directory.
Change-Id: I844f97acfabe6b54db85e7a7a0c9c25694452bd3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
Extend the example writing section to handle qml plugins. Detection
is based on whether the plugin config is detected an the target links
against Qml.
add_qt_qml_module() now uses the the public facing API underneath.
Change-Id: I2ccd06548e7b5b18c9dc3338b835bc115fa97809
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
In an extreme case where /bin/syncqt.pl does exists,
is better to check if the QtBase_SOURCE_DIR is not empty
to avoid a mismatch script version that is being used.
Change-Id: Ia5694eadc5517998b827eccf70bdf6f3c14ebfa3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Incorrect variable name was being used to set the target in the parent
scope.
Change-Id: I73ea644ebf94c9b9a62b34b1ad493e488729ff2f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In the future need will need to continue to tie qdoc runs still to
targets, just like with qmake. This change prepares us for that by
ensuring that add_docs takes two parameters and that any re-generated
CMakeLists.txt from now on gets it right.
Change-Id: Id0256dc1e2f2f59f3b4e4ca98f0d10d025d189fb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is similar to how we show the instructions when configuring
in qmake land.
Change-Id: Iabd28acc3d74fd0175eab812a412744dac89e6f6
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
By adding the path to the DLLs early on in the path. This fixes the
issue seen in CI (0xc0000135, DLL not found) and resolves local issues
where you might have forgotten to add this to path yourself potentially
grabbing libraries from elsewhere.
The ${path} seems to be a holdover that is no longer used, so it was
removed while the code was changed anyway.
Also disable WIN32_EXECUTABLE for all tests so that we can actually get
some output from them :)
Change-Id: Iec42c809c37be4f31c7f0a7af3a30c3528022dbe
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
Change-Id: I8113d7dd4e7967d020d59a5b4104e8366d55283c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Needed for qtcoap, otherwise AUTOMOC doesn't run moc
on qcoapnamespace.h.
Change-Id: I4ca43fcbbc5db6163f9f9f788b920eae86f5b174
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
In qmake, the header files used for private symbol versioning is done
via
private_api_headers = $$SYNCQT.PRIVATE_HEADER_FILES $$SYNCQT.QPA_HEADER_FILES
So we must do the same with CMake.
Change-Id: Iaebeb13592241b6c4d89f70d2e6ac3ebfb374207
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
BUILD_EXAMPLES and BUILD_TESTING are supposed to be defined via arguments
when executing cmake. The current text does not make that clear. Change
the wording, so that it matches other places in the document that explain
which cmake arguments to set when.
Change-Id: I058cf9d6bc7660c9f4820e2a7342bc64e99d6a72
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The if around the find logic meant that the module was never shown as
found after the first round.
Change-Id: I3dd47b37baf7c630c54adbce6872b99f9ff56ad0
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Output target was named output_target_quick instead of just output_target
Change-Id: I3ee0598bb61e654e42cb82b84da46f292d87e2cb
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Value was not being propagated to the parent scope when set.
This patch also changes OUTPUT_TARGET to OUTPUT_TARGETS since it is
possible that two targets can be generated.
Change-Id: If489a609ed363a319224fcd6c5a4fc878d0d8617
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
They're INTERFACE-type targets and can thus only have whitelisted
properties set. That fixes the cmake configure step for the UiPlugin
target in qttools.
This has the unfortunate side-effect that the headers will not be picked
up for our pre-compiled headers. Although it is not a big issue since we
don't have many header-only modules. An example is QtTools' UiPlugin.
Amends 2cf0ba1fba
Change-Id: If722928f64727ffaf2e9d0746668c0198fa1a647
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
Some modules define their own manually-maintained lists, and we can rely
on the headers generated by each module to include in the pch as well
e.g. QtCore/QtCore.
There's also e.g. QtWidgetDepends for QtWidgets, but this only
works for modules, not for tools, examples or other applications.
For now we'll use the Qt<Module>/Qt<Module> headers for the
modules we depend on.
Building with PCH can be disabled with -DBUILD_WITH_PCH=NO, and it only
works for versions of CMake newer than 3.15.20190829.
Change-Id: Iae52bd69acfdfd58f4cd20d3cfa3c7f42775f732
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Change-Id: Ie34c03c409a20546ace1ddc84f8813c1772936f7
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If syncqt was not executed for a module, it will not have generated
headers, so we should not propagate the include/${module} header
location in that case.
Change-Id: I6dc0628a11ababb4d237215a9f4d3fc331383848
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Qt CMake Build Bot
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
Fix the silly boolean logic error in commit
9c1b7802d7.
Change-Id: I9dd0d3e8be5cbe75583099686a623d81d3dd87fc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is similar to qmake, where the .prf files from the source
location of qtbase/mkspecs are used in a non-prefix build.
This means that if a developer changes the source QtBuild.cmake,
and then runs make in qtdeclarative, cmake will reconfigure
qtdeclarative because the timestamp of QtBuild.cmake changed.
Before this change you first had to make && make install in the
qtbase build directory, before qtdeclarative saw the modified
QtBuild.cmake.
This change also makes the module paths be prepended to
CMAKE_MODULE_PATH instead of appended, which means they will
take precedence to any path provided via command line.
Change-Id: I9178d5183a95b3b67bfe1b1fe91d3d3371ffe5c5
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Don't create the plugin config files when doing shared builds, otherwise
for example Qt6GuiPlugins.cmake will try to include the xcb plugin cmake
config, which in turn will perform a full-fledged find_package series to
locate xcb. When an application just uses find_package(Qt6Gui), then
that is not needed.
Change-Id: I1890aaa5be8e214151c65fa981f547a73c0ca7fc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
QtUiTools in qttools is a public module that has only headers, so it's
an interface library in cmake. That means INTERFACE_INCLUDE_DIRECTORIES
cannot contain paths to the source or build directory, unless they are
prefixed with BUILD_INTERFACE, which this patch adds.
Change-Id: I047700f447237dfbe5a901072eb413a159ae537d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Fix up the previous commit and use separate COMMAND parameters for
add_custom_command to ensure the expansion of the PATH. The injection
via -E env "/some/dir;%PATH%" does not work as the dollar expansion is
not applied when the ninja command uses cmd /C. This relies now on
undocumented behavior of cmake ;(
Change-Id: I5b5fc88e4c13f8fb6c6bba3131204c2eb35404d6
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Our tools are typically installed into the Qt bin directory, after which
they are useable right away on Windows, since the Qt dlls are located
there, too. An exception to the rule are tools that are built within a
module and used right away. At that point they are in the top-level
bin dir of the build directory, along with "local" DLLS they might need,
but with the Qt dlls out of reach. To cover this case, we need to
prepend a PATH adjusting command when using these with
add_custom_command.
Change-Id: I7f58581f5060c8004b5d1fa1f6f17297256783de
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Do not build examples in static builds as they are not prepared
for this configuration.
Change-Id: Ia0fd0a6cdfa3733bf13eb2ca8398668f26c0bedf
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In the ICC configuration we can't build the qtbase libraries with ICC
and qtdeclarative with gcc, mixing won't work well. On Windows we've
covered this compiler mixing scenario using our toolchain file, but the
ICC case makes it clear that we have to be consistent about caching the
compiler in the toolchain file across platforms.
Change-Id: Iad2005ab00655f902e5f5cea2f0563d790d8aa93
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Change-Id: I8cb97afaaed46ee64b5a133e797179d7ddecdeef
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When building QtQmlDevTools we don't generate syncqt headers, but the
non-existent include paths were still added, which means that anything
that used QtQmlDevTools would fail to configure (the standalone tests).
Make sure to only add the include paths if syncqt was executed.
Change-Id: I6d79ecf53e9a5d396e8df801584ce2c9f119f9be
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
Whenever the qml compiler is used to process qml files from a
resource, and there are no resources left after all qml files have
been processed, make sure to propagate the created resource target
to add_qt_resource, so that the target is associated properly with
an export name.
Additionally the generated qml cache loader file uses private Qml
headers. Thus the object library that contains the cpp file should
have qml as a dependency (and not the target that will link to the
object library).
Change-Id: Ib385a900823df3e015492cdd06acd8a0cb9f8e9a
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Override the default binary path for qmlimportscanner so that it points
to the host build specified via QT_HOST_PATH.
Change-Id: Ib0b47e61315c87ce6225e2d8ca84043cae03357d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Update Android build configuration to be compatible with the multi-arch
android build patch to qmake. We can now build and generate the apk
correctly. Executing on the device/simulator will only work once the
latest changes from 5.14 have been merged in.
We now replace target suffix with ${CMAKE_ANDROID_ARCH_ABI}.[so|a] so
we don't have to deal with handling targets which might have any of the
OUTPUT_NAME properties set.
The dependency and deploy settings generation has also been updated to
append the file contents to a string and then do a single file write
at the end.
Change-Id: Id3c5bd0428141ecaf962124a100390e3a4e41feb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qmlplugindump is not build during a Qt static build, so there's no
point in creating custom targets that would run the tool.
Change-Id: Id7d6d44da63312f298f46eab08a5637cb0c97c8f
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
At the moment we only support building with Emscripten, so that's the
system name to look for.
Change-Id: I08782ed0201da1593058bf1fb2ec61d6660802ed
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The first issue is that instead of arg_OUTPUT_TARGET we should use
rcc_OUTPUT_TARGET (there was also a typo in the OUTPUT word).
The second issue came with the fact that the object library targets
that were created for resources had a "Qt6::" namespace prefix in the
exported Targets files, and yet the link generator expression did not
contain the prefix. This failed when building qtsvg in a static build,
because the exported object library could not be found.
The solution is to use the TARGET_NAME generator expression which
takes care of adjusting the name of the target when exported, thus
making the linking work both when building qtbase and when building
qtsvg.
This had the fallout, that all resource object libraries need
to be associated with an export set and installed. This wasn't the case
for plugins, because plugins have an export name of the form
"FooTargets", whereas the export name for the resource object library
is "Qt6FooTargets".
Adjust the export names of plugins to be the same as for modules and
resource library objects (aka contain the "Qt6 prefix").
Change-Id: I1ca28d20c51e4447e5783cc20571a68ec77f6513
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Make sure to document both variables are required when invoking cmake.
Otherwise, one might be omitted causing side-effects.
Change-Id: I3390df1cb5352ea6113952c99fcedef5336f2fc1
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
* The -no-undefined linker option only makes sense for shared
libraries. The WASM build is a static build though.
* The -gc-sections linker option is only relevant for host tools
and certainly applicable to the WASM toolchain.
Change-Id: Ib8daec66a6d80f5025887448882dd891e6176268
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is a simple mis-understanding between try_compile assuming interest
in the launching part of the thing we try to compile and our
architecture test being interested in the binary.
Change-Id: Ie972b662b6f34699f566649bb2c1e29da35b58c3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add missing qml root path variable in the deployment configuration file.
Not having this variable will cause androiddeployqt not use the
qml dependency scanner to package all relevant dependencies.
This patch also fixes QT_ANDROID_BUNDLED_FILES files not being
processed.
Change-Id: I5bca33cdbb57098f283b38516b777571806da9e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Assume that interface libraries can't have plugins for now, otherwise
we'll need to change the "MODULE_PLUGIN_TYPES" property name to
include INTERFACE_ as a prefix.
Change-Id: I21b64179ded5fd10216d843a21ee149e002793f3
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
From all the observed cases, the parameters given to OUTPUT_DIRECTORY
tend to be CMAKE_CURRENT_BINARY_DIR, which was the default value. This
change is mainly to avoid add_qt_test failing if OUTPUT_DIRECTORY is
specified.
Change-Id: I26b931dd33ad1e991b64c14cc11b4b7a713fc858
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Prevent the quick compiler running on embedded test data for platforms
such as Android. This breaks certain assumptions about the test setup
otherwise.
Change-Id: I1026da3e16552256623de26b843ea32ed2c4260e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
On android test data is embedded into to the binary via resources. This
will not work with sourceless tests such as the qml only test cases.
Change-Id: I3ecf28223b3c7c6dae4ca3f15519adc028082598
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
When using the quick compiler to compile qml files, add an explicit
dependency on Qml. This will result in linker errors otherwise.
Change-Id: Ib7af0e8ec1b48822fd0d3c3556f10d24f10e7489
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Also add support for modules that have no private module counterpart.
Both are needed for Designer's QtUiPlugin in qttools.
Change-Id: Ia7e9d8837140e1de5cd59e196b4f63481ab68298
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Qt CMake Build Bot
Specifically what each of the list variables in
qt_internal_create_module_depends_file is used for.
Change-Id: Ie4f8c0d7387308518932d37e802ecaeb0572b955
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
The content of the generated header files should reference both public
and private Qt module dependencies. This is the same as what qmake
does.
Change-Id: I2e47c93291d677b86af7bb80fb788b2acf939743
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Qt CMake Build Bot
In some places of the build system we need to iterate over repo specific
Qt known modules (aka the ones that are built in the current project).
In other places we need to iterate over the whole list of known Qt
modules (those found via find_package + the ones built in the
current project).
Introduce two separate functions that provide access to either the
former or latter, and adjust all existing usages of QT_KNOWN_MODULES as
needed.
Change-Id: Ica96d0cfe690b9aaaa3f8c53bc84975bccad69c7
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
When building tests for android some resources names had the "#"
character in them which triggered a CMake error when use in conjunction
with add_custom_target()
Change-Id: If5f471eebb027683e86b0c4e38c2f34ff8891b7a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add missing required resource prefix to add_qt_resource() call when
embedding test data as a resource.
Change-Id: I9130f9ae863daae80221a1475b077b1d2e501f6d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This patch moves all of the underlying code for add_qt_resource
into a common reusable snippet for both the Qt build and user projects.
For users, the new API is available under QT5_ADD_RESOURCES. If
outfiles is a CMAKE target we will use the new API, otherwise
we will fall back to the old behavior.
This patch also adds EXTRA_CMAKE_FILES and EXTRA_CMAKE_INCLUDES to
add_qt_module so that module specific cmake files can be installed
and loaded by the module's config.cmake.
The code will be installed under CMAKE_BINARY_DIR/Qt{}CoreResource.cmake
and is injected into Qt{}Core_Config.cmake via the extra cmake includes
passed into add_qt_module.
To make sure it still works with QtBuild, we do the actual generation
of the file from QtBaseGlobalTargets and include the generated file
there as well.
Change-Id: I85fefaa11dde01a6790d23c62d6a64cd157e2617
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This condition was not being properly evaluated since the cached variable
was treated as a string. Any checks with if(QT_WILL_BUILD_TOOLS) would
just verify whether the string was empty or not.
Change-Id: Ie8b9ecc8249a1e9f5c0aa1b13d5bef686fcb04de
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When building qtsvg or qtimageformats there are a bunch of
configuration warnings like:
The plug-in 'qtiff' does not belong to any Qt module.
This happens because qt_get_module_for_plugin() checks for modules
only in the QT_KNOWN_MODULES variable. find_package()'d modules
will not appear there though, but only in
QT_ALL_MODULES_FOUND_VIA_FIND_PACKAGE.
Change the function to check for Qt modules in both variables.
This fixes all the warnings regarding plugins not belonging to a
module.
Change-Id: I39e668801a93794b62888cf868b97c55f57dccdd
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
I don't know why, but previously the test data was copied to
"test_build_dir/testdata" subfolder. That's incorrect, there's no
need for a testdata subfolder, the copied / installed contents
should go directly under the test build dir / install dir.
Incidentally this will make the corelib/io/qdir tests to pass.
Amends 1307736c7d .
Change-Id: I9e180d608433fe82f4a29afea7f594507e6020d3
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Teach pro2cmake to use add_qt_test_helper instead of
add_qt_executable when the qmake 'qt_test_helper' feature is used.
Don't use macOS bundles when building tests on macOS, because that
breaks path assumptions for certain tests.
Introduce a new OVERRIDE_OUTPUT_DIRECTORY option for add_qt_test_helper
that allows placing the binary into a folder other than the test parent
folder. I considered changing the default behavior not to place into the
parent folder, but that would break all existing tests, so I opted for
override approach instead. Ultimately we might want to revisit this
later.
Change-Id: I68fd1dea608333c2af0d3896050b40a6964dd87f
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Rename the alias property used by add_qt_resource() to QT_RESOURCE_ALIAS
to match property naming conventions.
Change-Id: I97b12b0b794e158f03dabeed5ec23a3b7d56cfbb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Support translating the QTQUICK_COMPILER_RETAINED_RESOURCES variable.
Fix missing PROPERTIES keyword for set_source_files_properties() commands.
Apply source file properties to standalone source files as they appear
in the project as it was possible for them to inherit values that were
not meant for them.
When creating resource lists, prefix them with the resource name
to avoid collisions.
Change-Id: I69ef85ea9414c0e7c07b1ebfb76d24bd878ce70f
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
When pro2cmake converts qrc files that are located in a subdirectory
there is an error in the resource paths for qrc files generated
with add_qt_resource().
For instance, consider the contents of data/scenegraph.qrc:
<RCC>
<qresource prefix="/qt-project.org/scenegraph">
<file>"shaders/24bittextmask.frag"</file>
</qrsource>
<RCC>
After processing by pro2cmake and add_qt_resource() we generate
<RCC>
<qresource prefix="/qt-project.org/scenegraph">
<file alias="data/shaders/24bittextmask.frag">
${CMAKE_CURRENT_SOURCE_DIR}/data/shaders/24bittextmask.frag"
</file>
</qrsource>
<RCC>
The expected qrc path for the resource should be prefix/shaders/...,
but in CMake it becomes prefix/data/shaders/... due to the
BASE parameter.
To fix it we check whether BASE is set and whether there are no
other aliases present on the source file before setting an alias
with the original file path.
Change-Id: If0a68a5ffa787704b10b740e20f875c9029509b0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Export the architecture configuration variables from QtBase. There are
other modules that require access to this information in order to
enable certain features (e.g: qml_jit in QtDeclarative).
Change-Id: If2c7f29ccb1c0b0a0db3d78ad133a2a6be12b5ad
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Added substituion rule to qt_internal_module_info to replace '.' with
'_'. Fixes compile errors for targets with names such as Plugin.2.
Change-Id: I0754c771bdc456a8a8f450fba90792c98d276c92
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
We now compile all qml files from the quick compiler in separate
directories qmlcache/${resource_name} to prevent issues where the same
qml file is present in more than one resource file.
Change-Id: I6857ff6aaaa21112896d5d39bbe11d3ffe524ec8
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
If the variable resource_files existed in the parent scope, the list
would now be duplicate.
Fix case where TO_CMAKE_PATH didn't properly convert //Foo into /Foo,
so wee need to handle this manually.
Change-Id: I73f1b4db82f6a80ba00da928b39091ac6c968a02
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This change makes the PREFIX parameter a required parameter if the
target does not specify a default. This way the behavior is clear when
reading the code: add_qt_resource() without PREFIX means it must come
frmo the target.
Change-Id: I79024e70e7b4d32a5164b93aa08ec9ff409b2d39
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
* Add support for a QT_RESOURCE_PREFIX target property, that
add_qt_resource respects. This makes it convenient to add files
to the resource system for a project without the need to repeat
prefixes. In qmake land with multiple resources they're repeated
in the foo.prefix variables or in the prefix attribute in .qrc
files.
* Since /qt-project.org/imports is in the default QML import search path
and the hierarchy under the import search paths is "regulated",
we might as well make add_qml_module set QT_RESOURCE_PREFIX on
the target. We can compute the correct value for that. This
allows removing the redundant prefix from the add_qt_resource()
calls for the qml files.
Change-Id: Ic15130dc9e432340fc3edf93e35f2a803b4b40eb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
There was a missing dependency rule which would cause the generated cpp
file to not be updated when changes were made to a qrc file generated
through add_qt_resource().
Change-Id: I9544c2fb6cf49529913f731b8fb6fc524d65e40c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Detect this in the conversion script and map it to a source file
property. When that's the case, avoid repeating the file list but
instead store it in a variable.
Change-Id: If3119d83914bb798766e27351746b4e867bd3ab3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Minor tweaks to make sure QML test cases without source files work as
expected.
Change-Id: I30b72622692b8f36d01f7a17b9d1456b0ab223ea
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
File passed into add_qt_resource are check to see if they match valid
qml files extension. Those which match the latter are then processed
by the qt quick compiler should the qmlcachegen target be present. We
also ensure that any remaining resources are properly chainloaded.
If the qmlcachegen target can't be located a warning be will be
issued asking for the inclusion of QmlTools in the find_package
command.
Change-Id: Ieecd38670e15c21d94dc549b31c7d87f2383d9af
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
While trying to port qtgraphicaleffects, when trying to configure
the project with a non-prefix build, the configuration fails with
the following error:
CMake Error in src/effects/CMakeLists.txt:
Imported target "Qt::Qml" includes non-existent path
"../qt_cmake/qtdeclarative_built_developer/include"
This is because we incorrectly export public include directories
that point to an "/include" folder under the repo build dir, whereas
in a non-prefix build the syncqt "/include" folder is actually in the
qtbase build dir.
Fix this, by introducing a new variable called "foo_repo_include_dir"
which will point to the correct include directory regardles of prefix
or non-prefix build. This variable is set by qt_internal_module_info.
Fix all relevant places to use this new variable. Also streamline
and remove any unncessary include directories in all our functions,
thus making everything consistent and hopefully easier to understand.
Change-Id: Icbe884701275c7754daecadcdba18048b4d779d0
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Perform the test whether tools should be built before entering the
source directory of a project. In QtDeclarative this would result in
a configuration error since the tools are used while building everything
under src.
Change-Id: I33ce2cb317ef221836d696654f3bb4e39db47e54
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make sure the URI name for qml modules correctly strips out the version
number for instances such as QtQuick.Controls.2.
Change-Id: I18e706b371323eeefdd6d7564b922265fa5cad3f
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The rcc generated code relies on global constructors to register the resources.
The object file of the generated code is included by default in shared libraries
and executables. However when the object file ends up in a static library, the
linker will discard the object file when nothing references any of the symbols
in that object file, when linking the static library into the executable/shared library.
The solution is to link the object file straight into the final target, by means of a
cmake object library.
Change-Id: I02ad1173e4f7e8f907022c906640dc9086233676
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Due to the missing argument processing on PUBLIC arguments we could
run into situations where the defines for an executable (mostly tests)
would be incorrectly processed.
If one were to pass a define into a test that also specifies public
libraries, the defines passed in by test would fall under the
PUBLIC_LIBRARIES argument in add_qt_executable.
For instance, in a test with DEFINES Foo PUBLIC_LIBRARIES Core
would cause arg_DEFINES to be "Foo=BAR;PUBLIC_LIBRARIES;Core". This
combined with the defines specified by add_qt_test would result
in the following string "Foo=BAR;PUBLIC_LIBRARIES;Core;TEST_DIR=..."
and would cause TEST_DIR to be treated as a public library in
add add_qt_executable.
For some reason I can't figure out, these two defines end up in the
linker flag section of certain test programs. There is nothing wrong
with the rest of the propagation chain into add_qt_executable. My best
guess is that it has something to do with the generators. In any case
add an explicit -D fixes the issue.
Change-Id: I340790c1c2426fa76785d1bd1b3332a904323d56
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It has been decided, that going forward all qml files are to be added
to a module via the resource system. This patch does the ground work
to make sure all qml modules in the qt codebase follow these new
conventions.
New properties on targets have been added so that we can't track all the
qml related information for later use.
To make sure it is still possible to install qml files we added the
qt_install_qml_files() command.
Pro2cmake has been adjusted to handle the special cases of versioned
qml modules (e.g: QtQuick.2). It will now insert a TARGET_PATH
override to avoid the default conversion from the URI parameter.
Finally, this patch temporarliy disables the quick compiler by moving
all relevant code into a dummy function. This will be removed in a
follow up patch where the quick compiler will be enable for all
qml files present in resource files.
Change-Id: I09fe4517fad26ec96122d9c7c777dbfbd214905c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This patch adds support for the qtquick compiler feature, which
will embed the compiled qml files as resources along with the
respective qml_loader.
This patch also changes the add_qml_module call to require either
EMBED_QML_FILES and/or INSTALL_QML_FILES to be specified.
Change-Id: I32d29c9b554b8286ed3b980027a56dd4abe11c92
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Make sure that the .qml/.js/.mjs files are copied or installed into
their target destination.
Change-Id: Ib1649e5168c9fe3a570800af92d82293e5b295d6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
When building qtdeclarative against a static iOS qtbase build,
QtNetwork is find_package'd twice, once in the top level
CMakeLists.txt file, and once by the qtuiotouchplugin which has
Network as a dependency.
This meant that the static plugins that Network exposes had
auto import cpp files generated twice, which failed the configuration
of qtdeclarative.
To fix this, don't generate the same file more than once.
To do that, protect the inclusion of the FooPlugins.cmake file, to
only be included once in every directory scope. That can be achieved
by setting a variable to TRUE when the target does not exist yet.
If the target exists in the same scope, that means that find_package()
was called a second time in the same scope, so there is no need
to include the Plugins file.
Change-Id: I9d7c3e7b7c22c2b4526cf1d717b9d15919f213f3
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
When cross-compiling qtdeclarative, add_qt_tools makes sure to import
the host tool and not build it. But there are also some
extend_target and add_qt_resource calls which try to extend the host
tool.
Make sure to protect those functions not to do anything if they are
called on an imported target.
Change-Id: Ifd8bcab8e56ad389a8c145382b23bd2c1bda5e81
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
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>
After re-arranging subdirs, the cmake target level dependencies can
handle building qmlcachegen before running the custom command for
generating cache files.
Change-Id: I8a35b2b5bfd2fdf4b49462ff9c27e5f3075254fc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make sure to handle glob expressions in the entire path given, not just
the end of the path. This handles tests like qsslkey and qnetworkreply.
Also copy/install the testdata in the final test directory path under
a "testdata" subdir.
Previously INSTALL_TESTDIR was used, which was never set to anything.
Change-Id: I2408e12f586cadeb524ffa249e851a4179324b23
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
This patch adds support for qmake's qmlcache feature. It's enabled
when option EMBED_QML_FILES is not present in add_qml_module.
Change-Id: I9b35f0bda7dfaf777f55c14eaf3d763f9b550fa4
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Some projects in QtQuickControls force the qml files to embedded into
the binary. This change exposes an option to mimic that bevhavior.
Change-Id: I4cbf0c21c05ca03b8dd1189eb7d81e43279c7157
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Extend add_qt_test for qmltest by setting the option QMLTEST
when we detect the config qmltestcase.
We also forwards the GUI option to the tests when detected.
This is a requirement for some QtQuickControls2 tests.
Finally when doing a prefix build, we add the install directory
to the QT_PLUGIN_PATH environment variable.
Change-Id: I3b2ecb494955976e98abbcf3d03925c314336122
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make sure that paths passed to qt_copy_or_install are prefixed with
QT_INSTALL_DIR so that they behave correctly with prefix and non-prefix
builds.
Make sure that plugin.qmltypes and qmldir are also copied to binary dir
when doing prefix builds to match qmake's behavior.
Change-Id: I6f87ed478e797c9f66dbf85264904ad29a60ad95
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
The build failed due to two different reasons.
We tried to assign properties on an aliased target, which does not
work. Make sure to set properties on the original unaliased target.
We tried to query for the value of the QT_DEFAULT_PLUGINS property
when automatically linking to plugins, but the generator expression
failed in the AND section, because querying for an unexisting value
does not return an integer, and the AND expression expects an integer.
The fix is to wrap the relevant expression in a BOOL generator
expression.
Change-Id: Ia065bc1de939cee49e5de0b2aef70e356cc5419a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
Some author warnings don't make sense when dealing with QML
plugins, like the messages regarding CLASS_NAME or not
belonging to a certain module. Take care not to print those
warnings in those cases.
Change-Id: I017bd63cca650dc262337949242e813b7b6a56cc
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>
Reduce the amount of code required to add a qml plugin to cmake
by making add_qml_module wrap the add_qt_plugin code where required.
add_qml_module will also create a dummy target so that qml files
will appear as source files in an IDE when no cpp files are present.
CXX_MODULE qmake parameter has been dropped in favor of an
explicit IMPORT_VERSION parameter, since it was only used to
determine the version when the IMPORT_VERSION was not specified.
Change-Id: I4a4b626566720d04c62d246ca521db8c4a95b10f
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
These changes enable the support to handle test data and install or
package them as resources when appropriate.
This change does not handle the GENERATED_TESTDATA or
TEST_HELPER_INSTALLS since there are very few occurrences of these and
we can handle those as special cases.
Finally, in add_qt_test, only append CMAKE_CURRENT_SOURCE_DIR if
the path is not absolute.
Change-Id: Ic20b9749d10e2a09916f2797606116471c64850b
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Add the necessary code to both the QtBuild and pro2cmake to be able
to handle qml plugins in qt declarative.
Add condition replacement for QTDIR_build to QT_BUILDING_QT so that
certain qml examples work correctly when being built in the build
directory.
Fix add_qt_resources not being updated during build after changes
were made. Files list used as dependencies were not populated.
Add missing module mappings for qtdeclarative.
Change-Id: I0f71d0a3a0e7e97ba96807950d11cffaee04d9b2
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
f66c1db16c in qtbase introduced a new
macro that the moc scanner has to look for.
Set an explicit list of macros to look for in the
CMAKE_AUTOMOC_MACRO_NAMES property of every target that has AUTOMOC
enabled, otherwise CMake AUTOMOC won't run moc on files that contain
the new macro.
Change-Id: Id991a70d773cef66716621803a88e96b44a80650
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This is done by adding a DEFAULT_IF argument to add_qt_plugin, which accepts
if-evaluated expressions.
e.g.
add_qt_plugin(myplugin
DEFAULT_IF ${foo} STREQUAL ${bar}
...
)
so that this mechanism can be reused later if necessary.
Change-Id: I7eba9adaaa28e55a4f0f94cf206e868b990027e6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Previously the cmake install prefix was added twice during a non-prefix
build, which evaluated to an incorrect path.
Set another absolute dir variable, and use that instead.
Change-Id: I73099510dadc8f401d5a763f21840c9671686c10
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
Add QtAutoDectect cmake which has routines to handle the vcpkg detection
as well as set up some android configuration parameters. The latter will
contribute towards keeping the cmake configuration commands shorter when
targeting android.
Change-Id: I721291c8dce39b5c298565a46867ddcab2df90e8
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Update the cmake README file with explanations on how to target the
other available Android architectures.
Change-Id: Id7653abc4a1a6fbb96797014ce2ca2e6bb49943d
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Mixing compilers won't work well on Windows, so if qtbase is built using
cl.exe and Ninja and then later cmake is called on another module and
gcc is found in %PATH%, then cmake will prefer that. Let's avoid that.
Change-Id: I8294482939efa6a16e0a4df8df3aeef8243c3657
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The run_config_test_architecture() function in QtBaseConfig was not
working correctly as we were not updating the length of the line
properly.
Change-Id: I29c5b45f1fa36d16cb2ef00950feb80987f6b176
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We need to save them in the toolchain file, otherwise we can't compile
anything :)
Change-Id: Ic5c53524fa4aa05d0b3229c2905dff92ca437ec1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
Generate the ${MODULE}-android-dependencies.xml for the androiddeployqt
tool. This will ensure all the right plugins and dependencies are
packaged when generating the apk.
This change also changes the visibility for executable to default/public.
Not having this will cause the application to crash as we can't locate
main() in the executable (shared library).
Additionally pro2cmake conversion script has been updated to perform
the required conversions for the Android settings.
Finally, the 6 projects in QtBase that have Android dependencies have
been updated with the new script and the step that produces the xml
files in run at the end in QtPostProcess.cmake.
Change-Id: I9774ba1b123bc11cae972fa37054ef2c51988498
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Similar to the shell script, this makes it easier to invoke cmake by
just extending your PATH.
Change-Id: I1f83e93c507032f6ecf4838c11d62f49f4d93ed6
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Just like with qmake, separate the two "features".
Change-Id: Idf2a796c7c4aaa740c471688b2221d7041fed643
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For ICU we have multiple components, and ICU becomes a public dependency
to QtCore.
When storing the INTERFACE_QT_PACKAGE_COMPONENTS property, make sure to
store the entire list of components, not just the first component -- by
turning the semi-colon separated list into a space separated list.
When processing the components at find_dependency time, we need to
reverse that and pass COMPONENTS directly to ensure a correct parameter
expansion.
Change-Id: I24a0708520e7d5fba039395a151034aee4d4c0e2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
* Add labels so that ctest --print-labels and ctest -L <label> gives
insight over the test plan and the ability to run easily individual
tests.
* Unfortunately we can't do the TESTARGS indirection for arguments as
coin does with testlib, so instead pass the parameters to generate
the xml unconditionally.
Change-Id: I289de9c15c516e3ac3fe04771fdbd8d7a083ff1f
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Due to scoping this variable needs to be written into the cache.
Change-Id: I2704fe9ac138210571e0b7acada5eb5c65e265af
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The current state of qtbase is confirmed to be built with no warnings
when using up to Xcode 9.2, as per the check in
mkspecs/features/qt_common.prf. Add the same check for the CMake
build.
Change-Id: I0c2409ece048e93fba29c41a8bd053dd112949bd
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
When cross-compiling we take a shortcut in add_qt_tool() for moc, etc.
as the tools are already imported from the host build of Qt. However we
must still add the tools as a dependency in for example QtCore so that
when the cross-compiled QtCore is used, the host tools are implicitly
imported.
Change-Id: I83e4fd7f21e18472c0965c90c058dd2b55b6ec65
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When the host system uses 64-bits for pointers and the target 32-bits,
then locating the tools dependencies would fail due to the mismatch.
Since the tools dependencies don't create linkable targets but merely
import executables, we can skip this check like in commit
914b367c7f.
Change-Id: I1ebd0867e4cce34f42df21dc8e8d9176a83a9cac
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This gets us a step into the direction of convenience that qmake
offered:
* QtBase is configured with a long command line (especially when
cross-compiling)
* Afterwards application developers (or other module builds) can
just use qmake && make
By generating a toolchain file we can capture vcpkg and toolchain
chain-loading and a shell script can take care of providing the prefix
path.
Change-Id: Ided81f5432cab862306f2bea86cfe8e56adf71b0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
add_library(MODULE) creates libraries with .so extension on macOS,
but Qt plugins should have the .dylib extension.
Change-Id: I603e7abfb9d5b78c0c8ea526f9fe995bf36c3a50
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
All the other PlatformModuleInternal, PlatformPluginInternal,
PlatformToolInternal target will depend on the common one.
Also add the QT_NO_DEBUG definition when the build type is not Debug.
This fixes the lookup of the Qt platform plugin on macOS, which
uses a "_debug" prefix in the plugin name depending on if the
QT_NO_DEBUG definition is present or not.
This is the same as it is done in mkspecs/features/qt.prf.
Change-Id: I82cf461d44b8a3b3c5dc2b2d9f25baa246fc1e4b
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
We want our libraries to end up in the same bin directory, not inside the
Debug\ or Release\ sub-directories. Their distinct names avoid a clash.
For our tools such as moc, uic, etc. we need to place the release build into
the bin directory explicitly, as by default multi-config generators place
binaries into the Debug\ or Release\ sub-directory.
This is also needed as cmake's automoc itself expects moc to be in the
bin directory.
One effect of this is that with a multi-config build, it is always necessary
to perform a release build first, otherwise the debug build won't find moc/uic.
Change-Id: I1361823ddf5961a5f1bb517e4bca69e621cbce9e
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If VCPKG_ROOT is defined, let's use it and chainload any previously set
toolchain file. The detection of vcpkg support via the VCPKG_ROOT
environment variable is per vcpkg documentation, the automatic
chainloading is something specific to us.
Change-Id: I0498effc5b948f0b6f5e223d0454a15a0cbb503a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
As per vcpkg documentation, this is a tweak that allows respecting the
vcpkg default target triplet environment variable, which simplifies the
command line slightly.
In order to make this also work for modules other than qtbase, we're
going to need to consider the creation of a toolchain file.
Change-Id: I2573f6644d671c710fd823df83e2205dbbfe19e6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
Remove the special case in QtGui and instead handle this in a generic
way so that QtPrintSupport is covered, too. For now we do this in the
same function where we run the regular target install() commands. It
doesn't quite fit into per-target PUBLIC_HEADER or PRIVATE_HEADER
properties as the qpa headers sit _next_ to public and private in a
separate qpa sub-directory.
Change-Id: I30aadaf9496cf0236f39a7c36a5163e4270edecc
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Always install - not installing doesn't make much sense.
Add information about developer-build.
Change-Id: I406d007e9b167ee83d126ffa6e78235743402c33
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
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
Builds fail on Windows, due to splitting on ':' on absolute file paths,
when handling syncqt injections.
Revert for now to get qt6 merge in faster.
This reverts commit 7559d508d1.
Change-Id: If139a8a1eb4ae7ccc8d7b835b12e83b03176e28b
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Reviewed-by: Qt CMake Build Bot
In case of a CMake superbuild, the actual install root in a non-prefix
build is the top-level build directory (not $TOP_BUILDDIR/qtbase anymore).
This is more in line how CMake lays out things by default.
Task-number: QTBUG-75582
Change-Id: I4e1744b5c877508fedc33e237eec28cb7436010b
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
in qt_build_repo().
This is important for qtdeclarative for example, which builds QmlTest
functionality in ./src, and thus needs Test lib to be available.
Change-Id: I84326d79844526f2f177c19de30bab0c858773e3
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Instead of doing it just in qtbase/src, we need to do it
for all repos before building ./src.
Change-Id: I57f226b849cd5370ffbbbea8a694697d400957a4
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
The GlobalConfigPrivate target should also be filtered out when
registering target dependencies, because there's no standalone
Qt5GlobalConfigPrivate.cmake file.
Amends fbfa067a30.
Change-Id: If89732bc2fd004b9644959f71339e22210483d7c
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
There were a few issues:
- Third party dependency info for plugins was not generated,
because the depends and public_depends variables were not fetched.
This caused issues when trying to use the qcocoa plugin in a
consuming application, because Cups::Cups was not found.
- Privately linked libraries in extend_target were not considered when
generating dependency info for modules. This caused issues in
QtThemeSupport, becauese it could not find Qt::DBus, due to that
target only being added as a private library in a conditional scope.
- Make sure to handle privately linked internal modules like
PlatformModuleInternal to map to the Qt5 package, because there is no
standalone package for it.
Also remove a TODO comment that says that qt_register_target_dependencies
should maybe be called in extend_target. That's already the case.
Change-Id: Ie99c52e800cd89e6f82008f1e38f4da5cd602929
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
In Qt 5, the Qt5Core target was extended by Qt5CoreConfigExtras.cmake to
have a generator expression as interface linkage that would
conditionally link WinMain.
This patch implements the same through regular interface linkage right
in corelib. Since the linkage happens through a generator expression,
our dependency generator does not see this as a dependency. Therefore we
add this as an unconditional package dependency for corelib, on Windows.
In theory this could be done also in winmain's CMakeLists.txt, as
targets can be extended outside of their directory. However this adds a
directory id (WinMain:@<023423>) to the linkage, which mysteriously is
not removed on the exported core target.
Change-Id: If2abb9ba790f51274f582c9ec28c13d968b84302
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
* Simplify add_qt_gui_executable() to not require WIN32/MACOSX_BUNDLE
but provide it implicitly. It's redundant :)
* When on Android, build a module (shared library), just like qmake.
This requires an additional library destination in the install() call,
but that's ignored on other platforms.
* Fix typos in the android deployment generation settings function
* Use the correct cache variable to determine whether we're inside a Qt
build or not. Right now this only works inside Qt builds anyway as
QtPlatformAndroid.cmake is not publically accessible.
Change-Id: If1c763c31a7a83d0e0d854362ba7901657f63eb5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
Provide add_qt_gui_executable() as function in our public API that takes
care of automaticWinMain linkage. We can use this in the future to
encapsulate similarplatform-specific behavior and adjustments, such as
module generation onAndroid.
In order for the examples to see the function in Qt5CoreMacros, three more
additional fixes were required:
* Do the build_repo_end() call _before_ attempting to build the
examples, as we need the build_repo_end() to include QtPostProcess
and complete the creation of all the target config files.
Otherwise the find_package() calls in the examples see something
incomplete.
* Add more QT_NO_CREATE_TARGET guards
* Always call find_dependency on the dependencies, regardless of the
target creation mode. This way a find_package(Qt5 COMPONENTS
Widgets) will still load Qt5CoreMacros.
Change-Id: I03ce856e2f4312a050fe8043b8331cbe8a6c93e6
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Commit abe12f600b moved the
_LARGEFILE64_SOURCE define to a central place and commit
449eee2d10 made it conditional to UNIX
(not WIN32). Somehow these two were left over though.
Change-Id: I23b08e84db804e9d5a4dde706af501c0918b460e
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's already installed right where QtSetup.cmake is installed.
Change-Id: Ie88363ae3878cda8f92aa44160333886f64565d8
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
In qmake land warnings_are_errors is only enabled for specific
MSVC versions, ending with MSVC2015. Presumably the warnings have not
yet been fixed for newer MSVC versions, so we stick with the same
status quo for now.
Change-Id: Idc3741d39c888f77ed324a5eb8c654416591785f
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
In qmake land, the largefile.prf feature is automatically loaded due
to 'largefile' being added to CONFIG via the equivalent feature.
The prf file is in the 'unix' subfolder though, which means that qmake
doesn't load it on Windows.
We need to do the same, otherwise we get build errors due to the
define being checked in ZLIB headers, and selecting an invalid code
branch on Windows.
Change-Id: Ibe9202a639754927262bb8aaa28289934f2e23ef
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This is needed for QmlDevTools in qtdeclarative.
Change-Id: I41adec15f292c91192e171b45d1e5d48764c37c4
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This is needed for qtdeclarative, to automatically start building
the tools if needed.
Change-Id: I3cbe129e8bb6fa8572a8e34fd3653b51727cb244
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Move flags/options that we use for modules from add_module to the new
platform module target.
Change-Id: I89e414690336dcd37253432fe5116226d1c8dd82
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
extend_target.
In extend_target(Foo) we go over all the ModulePrivate dependencies
to assign them to FooPrivate. To do that we use the QT_KNOWN_MODULES
variable.
The problem is that the variable gets reset when we build a new
repository, so when we build qtdeclarative, QT_KNOWN_MODULES has no
entries for Core, Gui, etc, but only Qml, Quick, etc.
And yet QmlPrivate has to depend on CorePrivate.
Change the module Config.cmake files to append their target name
to a global variable called QT_ALL_MODULES_FOUND_VIA_FIND_PACKAGE.
The global variable gets populated every time find_package(QtFoo)
is called.
Use the union of QT_KNOWN_MODULES and
QT_ALL_MODULES_FOUND_VIA_FIND_PACKAGE when considering FooPrivate
libraries.
Change-Id: Ibd9449744478cea58eb5d9737cc8887b4df92420
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Added qt_examples_begin() and qt_examples_end() macros to setup the
example list so it can be re-used in other projects.
When cross-compiling, we also need to set
CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to BOTH in order for find_package()
to work correctly.
Removed support for building the whole qtbase/examples folder as a
standalone project. Building examples is only supported when building
the whole of qtbase (qtbase + examples together) or each individual
example is built separately against an installed Qt version.
Change-Id: I9d26b94b48b95af230b76ab618becb21d2d45581
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>
Don't try to report an installable public module .pri file for internal
modules.
Change-Id: Ide6a50420e0b5448b141c842df4c891baca4a9d9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
Link to them from add_qt_module/plugin/tool
This way we set the warnings_are_errors flags just once
and also non-qtbase modules get them
Change-Id: I2b65a81694aaebdd7c886249f217c11f79492bad
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
... in superbuilds. PROJECT_SOURCE_DIR points to the wrong directory in
that case.
Change-Id: Ic0cba254734c4693b418dd8a0d8e77063914a9de
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Generate a pri file for public and private interfaces, but map CONFIG +=
internal_module to a cmake option and skip the former if set.
Task-number: QTBUG-75666
Change-Id: I3f4baf1277094f4c22149a9e8769734baf9a235f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Enable building androiddeployqt when performing host builds only.
Added QtPlatformAndroid.cmake to locate Java and the setup the
android SDK platform when building on android.
Install the androiddeployqt support files when performing a host
build.
Added ANDROID_SDK_ROOT configuration variable for specifying the
android sdk directory.
Generating the deployment-settings.json will be done in another
change.
Change-Id: I1bf15315af4ed904d2fb1d22b0e8e834df32d6ed
Reviewed-by: Alexandru Croitor <alexandru.croitor@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 modules, plugins and tools only (i.e. no tests nor examples)
this mimics the qmake behavior
default value is developer_build
Comes with some fixes in qmake since it seems in the qmake built it was
not having Werror, now does because we built it with add_qt_tool
Change-Id: I6f3237f25a6fedefa958644929e90f13837a12df
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This mirrors what happens for qmake. qt_plugin.prf does not
define these, but qt_module.prf does.
Change-Id: I742d3c766f6f4bd129fa6ccf85b5a67c6758e819
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
This was added to the qmake build system in 220028d37c
Change-Id: Ieee8b4d47b8f9716c14c85cf3038f1074ee8c46a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Create CMake config files which can be used from the very same CMake
project. These CMake config files simply do not create any targets,
controlled via the QT_NO_CREATE_TARGETS.
This patch also allows to build qtbase.git:examples as a standalone
project, against an already-built Qt.
Ran this:
ag -s "QT " examples -l -0 | xargs -0 -n 1 .../util/cmake/pro2cmake.py --is-example
Task-number: QTBUG-74713
Change-Id: I44cce5a4048618b30f890c5b789592c227a8b47d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
targets. This created issues when trying to build standalone examples.
Change-Id: Iaaea2b537793ae25fbf3143cc205574446aa4ad1
Reviewed-by: Kevin Funk <kevin.funk@kdab.com>
The WrapPCRE2 package handles the PCRE2 packages that have targets,
and reuse them.
Change-Id: I24b0b51f507703cd8287f845f7e425f62dd2c3d6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Otherwise when compiling qxcb-glx-integration we would get a warning like
<command-line>: warning: ISO C++11 requires whitespace after the macro name
because -DQT_BUILD_QXCB-GLX-INTEGRATION_LIB is not a valid define name
Change-Id: Ie8cef93a47b14d75eaad77893f7182e1514dd616
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
We introduced WrapOpenGL to link against either desktop GL or GLESv2
depending on the GL feature in QtGui. This works "fine", with two
caveats:
(1) find_package(WrapOpenGL) must be called after
find_package(Qt5Gui) in order for the feature check in
FindWrapOpenGL.cmake to work. That's error prone.
(2) More and more places are popping up, in particular examples,
where GL linkage is required due to inline functions in Qt that
forward to GL functions - such as on Android.
This in particular explains the qmake behavior of making the GL
linkage (desktop _or_ GLES) a public dependency of QtGui, so only
Gui linkage is required.
Those two aspects combined are the nail in the coffin of FindWrapOpenGL
and it would seem much easier to simply make the Desktop GL vs. GLES
decision once in Gui's CMakeLists.txt and let Qt5GuiDependencies.cmake
propagate this well. This allows us to get rid of plenty of special
cases as well.
Change-Id: I3a7e8af49537ce5f215f24470e075a4ae9aeb944
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Some features check for module / target existence. Adapt conversion
script to handle that.
Reland after fixing it.
Change-Id: If4fb942c2e0d16e76a0b9b767bf478527851b0f7
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Only re-enable exceptions for the modules that do
CONFIG+=exceptions
in qmake
Change-Id: I9f19078adbdc1b8fa3d4102fb51a099e7e35522e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
In particular, Qt targets extended with other qt targets
(eg. Qt::VulkanSupport or Qt::LinuxAccessibilitySupport)
after the first add_qt_module were not taken into account when generating
Depends files.
Note that this patch updates the minimum required version
to CMake 3.15
Change-Id: I747deedd4d59e385876bc1a834ef9bdb6078911b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It breaks some conditions, and then the build fails not finding
some private header files in qpa, etc.
This reverts commit 35dc8f496d.
Change-Id: I1b51eac06fe9186181d3f0a7c78f22da7be534e2
Reviewed-by: Tobias Hunger <tobias.hunger@qt.io>
Some features check for module existence. Adapt conversion script
and QtBuild feature condition parser to handle that.
Change-Id: I063e49a6fe9f8e9cf3aec985fd78ed4430398586
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
so they are actually set for all the targets
and that the code is a bit simpler
Change-Id: I2cd253d0a3cec3f482b868f81e852edfa158d3f1
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
