In the plugin test in QtBase we have a scenario where we have target
binaries that are inputs to add_qt_resource(). If we do not remove these
files from the dependency list for add_custom_command() cmake will
fail to generate the build files.
If we mark them as generated source files, we'd have to add a special
rule to generate them. Furthermore, using $<TARGET_FILE:...> does not
work due processing done by add_qt_resource.
To bypass this we check whether the property is set and instead of
adding the file to the dependency list we add the target referenced
in that property. RCC will still work as expected but will fail if the
files aren't present.
Change-Id: I16855a54f5606d6fe27ab1347ed7ff4f40392c98
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
OUTPUT_DIRECTORY by itself is not a valid cmake target property.
Change-Id: Ic3a2a81b8b982ad7ccf0551000a157f9a4d3ef22
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Note the following bigger things that had to be done:
Handle GSS library / feature with a new custom find module.
Implement rudimentary support for relocatability (does not currently
handle extprefix).
Change-Id: Ic6cd27dda7ebca9829f51cb42ea76fff6d1767ef
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
If a module is marked as NO_MODULE_HEADERS, we shouldn't
try to include the non-existing include directory which is
usually generated by syncqt.
Note it seems that NO_SYNC_QT and NO_MODULE_HEADERS seems
to converge, so it might make sense to merge them in the future.
Change-Id: Iab4e2907ed68776632337b37496b015535da8784
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Generated plugin CMake files should always try to call
find_dependency, especially in static builds.
pkg_check_modules sets a cache value for foo_FOUND instead of
a directory scope foo_FOUND, which means that find_dependency
will not be called in another scope, and thus fail to create
needed imported targets.
Note this makes the code be the same as in
ModuleDependencies.cmake.in.
Change-Id: I0b58b038afcb72cb27d0b433371bc9cb5e4bfec9
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Add condition replacements for the android ABIs.
Add a replacement for QT_ARCH to ANDROID_ABI, since QT_ARCH is only used
with the android build for now.
Change-Id: I553d7910546de32236f723ec2e9a05a18da76130
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
extend_target() does not handle the OUTPUT_DIRECTORY argument, so we
must handle it ourselves.
Change-Id: I31880a516ae185f3255b2a51f41d61ee6b1d9838
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's probably best to make it follow the usual calling convention that
the associated (consuming) target is the first parameter of the
function. So first this change accepts both formats.
Change-Id: I1f20706b23d5e819e0eb689eecedb3afb49df3b7
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Provide a SKIP_INSTALL argument to add_qt_plugin for test cases with
plugins lacking install information.
Change-Id: Iddb3843fab1790d69d64686530a46057a2ff0477
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add add_cmake_library to allow us to create normal cmake targets using
all the information we have collected via the conversion script.
This function is only meant for tests. For an example,
see tests/auto/corelib/plugin/qpluginloader/lib/lib.pro.
Change-Id: I738cb8ac241b8da1a1da3ef957c24dc7a754d43f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When we run into a plugin that does not have a type and is not a
qml plugin, we try to see if we can find the target installation path
and provide INSTALL_DIRECTORY AND ARCHIVE_INSTALL_DIRECTORY to the
add_qt_plugin call.
We run into this frequently with the unit tests.
This patch also changes add_qt_plugin() to use the value provided in
INSTALL_DIRECTORY for ARCHIVE_INSTALL_DIRECTORY if no value is provided
for the latter.
Change-Id: I61278904a4d2d72308079cd362bd085b4e2f540c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
QtPlugins.cmake.in uses file(GENERATE) and target_sources() to
propagate the generated cpp files which contain plugin initialization
code to their consuming targets.
Unfortunately due to a bug in CMake, if the file is generated in a
different scope than the consuming target, the CMake generation
step will fail saying that the source file can not be found.
See https://gitlab.kitware.com/cmake/cmake/issues/18399 for details.
In the case of qtdeclarative, find_package(Qt6) is called at the top
level scope (this is when the file gets generated),
but the targets are created in subdirectory scopes, and the GENERATED
source file property is not propagated across scropes.
Circumvent the issue by instead using file(WRITE) and configure_file()
which create the file at configure time rather than generate time.
This will pollute the current binary directory with some more files,
but at least successfully fixes the build.
Change-Id: I3ab3b12dcbf6a9d0ab9ee87173e4a1952325b37b
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
Some work was needed to make the plug-in types,
and which plug-ins are available for each type
in client code.
Change-Id: Ib71feca31069deca3d3f54c8613054f5f8ae410c
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Qt CMake Build Bot
Update add_qml_module() to use the new INSTALL_QML_FILES argument from
qt6_add_qml_module().
This patch also updates pro2cmake.py to remove the QT_QML_SOURCE_INSTALL
property from qml files.
Change-Id: I6623b2de76bb55bd6750e48f7d45c53ca536b391
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Update to match latest changes to QtDeclarative.
Change-Id: Ie455c0418e95c288149b4b1a29b065a8876e8b7e
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The framework is needed for qtconnectivity.
Change-Id: I6a502564fb5543ca94ba5ae458a544286e34564c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
Sometimes when writing a qt_find_package and configuring a project,
you might get the following error from CMake:
CMake Error at QtBuild.cmake (set_property)
Attempt to promote imported target "WrapFreetype::WrapFreetype" to
global scope (by setting IMPORTED_GLOBAL) which is not built in this
directory.
This means that another find_package call, found WrapFreetype
in another directory scope other than the current one, and thus the
found target cat not be made global. Sometimes that implies that the
qt_find_package might not be needed if WrapFreeType will always be
found via a transitive depdendency.
By setting QT_DEBUG_QT_FIND_PACKAGE=1 on the command line, you can
make qt_find_package skip all of its behavior if the package was
already found and the provided targets were also found.
Unfortunately this behavior can not be made the default, because there
is no way to find out in what scope the package was found, and if it's
legal to make the targets global. At least I haven't found a way to do
that yet.
Thus the opt-in QT_DEBUG_QT_FIND_PACKAGE is a means to help with
debugging such cases.
Change-Id: I04242ed0f2fd0a75bc199386d28a1a0bd92da41a
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
During a static build we need to use the find modules
in 3rdparty/extra-cmake-modules/find-modules when generating a
ModuleDependencies file, so that the generated find_dependency()
calls succeed. This means that the files have to be shipped with
Qt6 package, making them pseudo public API.
There is also a need to use these files when building QtWayland.
Instead of setting / unsetting CMAKE_MODULE_PATH only in module
and plugin Dependencies cmake files, just set them once when finding
Qt6.
This will allow QtWayland and QtX11Extras to easily find the required
third party packages, without having to hardcode the paths in multiple
repos.
Change-Id: I750d0421a269e5632afa1bb62498c2501d73cdb1
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
At least on Ubuntu the name of the pkg config package
is libsystemd and not systemd.
This fixes libsystemd showing up as not found in the feature
summary.
Change-Id: I099a253026ca8096b9e2f348a5f35209d44acc6c
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
Reviewed-by: Qt CMake Build Bot
If the target exists or the find_package() call succeeds
we still need to set _FOUND to 1.
Change-Id: Ib2267c30580082dcc177ab21708a3bc5dbde974f
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
Reviewed-by: Qt CMake Build Bot
qt_find_package usually does 2 find_package() calls, one in CONFIG
mode and one in MODULE mode.
If the CONFIG mode doesn't find a Config file, the package_DIR cache
variable is set to NOTFOUND, and this causes the FeatureSummary
at the end to show that the package was not found, even if it is
found by the next MODULE mode find_package call.
Make sure to unset the _DIR variable in case if the Config module
call fails.
This fixes XRender showing up as not found even when it's found via
the FindXRender.cmake file.
Change-Id: I6ce39dad9cbb11836ca71f735a3267070c75b444
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
Reviewed-by: Qt CMake Build Bot
This is needed because the ported over requires() clauses from qmake
to CMake are executed before qt_repo_build(), which means that all the
custom platform variables that we set (like LINUX, APPLE_OSX) need
to be available immediately after finding BuildInternals.
Change-Id: I7345b69edf72c266508846766e64f42c99862d1d
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Allow setting feature defines to ON, YES, TRUE, Y, OFF, NO, FALSE, N and
non-negative numbers like it's possible for other defines.
We'll not allow IGNORE and NOTFOUND, because they're a bit strange in
the context of features.
Change-Id: I7f6cd6dff4c68972921b499b28916c9ad789d510
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CMake Build Bot
The set command looked like this:
set \"PATH=...\"
which was setting the environment variable \"PATH.
Removing the escaped double quotes makes it actually work.
Change-Id: I2c1d5d01b4415220512b005b75b7b67c695e33ae
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
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
