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
