Add the generating of private cpp exports for Qt modules.
Add the GENERATE_PRIVATE_CPP_EXPORTS option to qt_internal_add_module
that is the manual switch for private exports generator. Existing
modules in qtbase doesn't follow any strict convention of using
private cpp export. So there is no clue how to detect if generating of
the private exports is required or not for the module.
Use autogenerated private cpp exports in QtNetwork module.
CPP_EXPORT_HEADER_NAME argument of the qt_internal_add_module function
is replaced by the CPP_EXPORT_HEADER_BASE_NAME and has a different
meaning. The provided name is used as a base name for the private and
non-private headers that contains cpp exports. Header files suffixes
are constant: .h and _p.h for the non-private and private header files
accordingly.
Pick-to: 6.2
Task-number: QTBUG-90492
Change-Id: Icf11304e00379fb8521a865965c19b974e01e62f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Add infrastructure to build cmake auto tests in the CI when targeting
iOS.
Currently the are only CI instructions for qtbase.
More work is needed to make it work for other repos.
With this change, we will build a single Widgets application targeting
the iOS simulator. We can't target the device SDK in the CI because
signing fails due to a missing signing certificate and provisioning
profile.
The Coin instructions will now set a QT_BUILD_ENVIRONMENT=ci env var
whose value will be checked in _qt_internal_test_expect_pass, to
ensure we build for the simulator SDK when using a universal Qt.
Without this, xcodebuild will try to build with the device SDK and
fail to build the project.
Pick-to: 6.2
Task-number: QTBUG-95839
Change-Id: Ib39c9527b107b2004746ccbdc9d9d1d658f88c76
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
qt6_enable_object_libraries_finalizer_mode is not needed anymore
now that static Qt builds require CMake 3.21 and thus CMake takes
care of placing object library object files at the beginning of
the link line.
Rename qt6_enable_import_plugins_finalizer_mode to a more generic
qt6_set_finalizer_mode that can enable or disable multiple
different modes.
For now the only available mode is "static_plugins" which handles
the behavior of the old function name.
The mode can be enabled by calling
qt6_set_finalizer_mode(${target} ENABLE MODES "static_plugins")
Note that the function is re-tagged as being in Technical Preview.
Ideally we would not need it at all. But we need to provide some
workaround for the limitations of linking Qt static plugins in CMake
on Linux-y platforms that use bfd ld or ld.gold.
The workaround does not work well with dependencies wrapped in
generator expressions which is why we can't confidently advertise it
as a proper solution.
Our hope is that this can be fixed in future upstream CMake versions
and the function can be removed.
See 6fcc272ac9 for details.
Adjust the tests due to the renamed and removed functions.
Amends 19e789bace
Amends cdbb390c4a
Amends a25027eecb
Amends 6fcc272ac9
Amends a3c430f390
Pick-to: 6.2
Fixes: QTBUG-95169
Task-number: QTBUG-95601
Task-number: QTBUG-95603
Change-Id: I51b85f776ec29fc04fed1a637eba7d1f60609e69
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The intention is to remove TYPE as a keyword completely before 6.2.0
release, but in case if that's not possible due to the large amount
of repositories and examples, just print a deprecation warning for
now and handle both TYPE and PLUGIN_TYPE.
Task-number: QTBUG-95170
Pick-to: 6.2
Change-Id: If0c18345483b9254b0fc21120229fcc2a2fbfbf5
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
CMake 3.21.0 + Ninja now pass absolute source file paths to the
compiler which causes __FILE__ to be absolute and qFindTestData
to ignore any QT_TESTCASE_BUILDDIR value.
This causes the test to fail, because it won't find test data in the
custom specified location.
Disable the test for now.
Amends 70464b355e
Pick-to: 6.2
Task-number: QTBUG-95268
Task-number: QTBUG-95018
Change-Id: If99035e897ac1d5f153d4e19c94e4355f88970af
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
target_link_options are placed by CMake at the beginning of a linker
line. This gives us an opportunity to use the function to propagate
object libraries. This change adds one more check in the root
Config.cmake file. If CMP0099 policy is enabled, CMake enables
propagating of the linking options when linking two static libraries
using the PRIVATE linking visibility, so we can rely on the correct
linking order and expect object libraries to be propagated.
Note that on the platforms where cmake version is higher than 3.16
Qt uses CMP0099 NEW in functions like qt_add_executable. This means
that at the moment of creating an executable target the TARGET_POLICY
genex will also be NEW, so we do not take into the account the user
defined CMP0099.
If the CMP0099 policy is not available for a certain CMake version
we skip the TARGET_POLICY check and simply disable propagation of
the object libraries using target_link_options for both user and Qt
libraries. This is applicable for the CMake versions 3.16 and less.
Linking approaches have the following priorities(from higher to lower)
after this change:
- target_link_libraries - works if link order matters not or CMake
version greater equal 3.21.
- target_link_options - works if CMP0099 is set to NEW by user or
if the CMake version is greater than or equal to 3.17 and an
executable is created using Qt functions.
- object library finalizer - works if CMake version is greater equal
3.19 or qt6_finalize_target is called explicitly.
- target_sources - is used when all the other approaches could not
be used.
Amends a1fd4f51ad
Amends 3329212815
Pick-to: 6.2
Change-Id: I14f88caeb04e357191c840abeab89b03e210b796
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add an option that automatically generates an export header for a Qt
module. The header contains only Q_DECL_EXPORT/Q_DECL_IMPORT related
content, so it's not a full replacement of 'global' header files.
Task-number: QTBUG-90492
Change-Id: I250d1201b11d4096b7e78e61cbf4565945fe6517
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The linking logic of object libraries should be reusable outside of the
resource context. This introduces a
__qt_internal_propagate_object_library function that prepares all the
necessary genexes to link and propagate the object library to the
end-point executable.
Rename resource object finalizer API to make the naming more generic
to object libraries of any kind.
Amends 5fb99e3860
Pick-to: 6.2
Task-number: QTBUG-93002
Task-number: QTBUG-94528
Change-Id: I69d0f34c0dadbd67232de91035aaa53af93d1fa1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For user projects we run the static link order check once
'find_package(Qt6 ...)' is called.
If linker can resolve circular dependencies between static libraries
and object files we set the _qt_link_order_matters property of the
Qt::Platform target. This indicates the use of finalizers is not
required and we may rely on CMake-base propagation of resource
libraries and resource object files.
If linker could not resolve circular dependencies depending on
the _qt_resource_objects_finalizer_mode value:
- Finalizer will be called and collected resource objects will be
linked to the target directly.
- Finalizer will be omitted and resource objects will be linked
using the target_sources function implicitly. This only
propagates resource one level up if consumer links the static
library PUBLICly, but all symbols will be resolved correctly
since object files are placed in the beginning of the linker line.
In the CMake version 3.21 we expect that CMake will take care about
the order of the resource object files in a linker line, it's
expected that all object files are located at the beginning of the
linker line.
TODO: Need to confirm that the CMake 3.21 meets the expectations.
Amends 4e901a2f99
Pick-to: 6.2
Task-number: QTBUG-93002
Task-number: QTBUG-94528
Change-Id: Ia68976df8182d3d3007b90c475c1e3928a305339
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
User projects can set the QT_PROMOTE_TO_GLOBAL_TARGETS variable to
true so that the various imported targets created by find_package(Qt6)
are promoted to global targets.
This would allow a project to find Qt packages in a subdirectory scope
while using those Qt targets from a different scope.
E.g. it fixes errors like
CMake Error at CMakeLists.txt:5 (target_link_libraries):
Error evaluating generator expression:
$<TARGET_OBJECTS:Qt6::Widgets_resources_1>
Objects of target "Qt6::Widgets_resources_1" referenced but no such
target exists.
when trying to use a static Qt from a sibling scope.
Various 3rd party dependency targets (like Atomic or ZLIB) are not
made global due to limitations in CMake, but as long as those targets
are not mentioned directly, it shouldn't cause issues.
The targets are made global in the generated
QtFooAdditionalTargetInfo.cmake file.
To ensure that resource object libraries promoted, the generation
of the file has to be done at the end of the defining scope
where qt_internal_export_additional_targets_file is called,
which is achieved with a deferred finalizer.
Replaced all occurrences of target promotion with a helper function
which allows tracing of all promoted targets by specifying
--log-level=debug to CMake.
Pick-to: 6.2
Fixes: QTBUG-92878
Change-Id: Ic4ec03b0bc383d7e591a58c520c3974fbea746d2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
QT_NO_INTERNAL_COMPATIBILITY_FUNCTIONS has been removed
Change-Id: Ic77cdae4e5151e3b0fe05cc6dd5b43bffc24768c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
'ld' only capable to resolve circular dependencies by wrapping the
suspected static libraries and objects using --start/end-group
arguments. We want to detect if linker is 'ld' at configure time to
decide how to link the resource objects if finalizers are not enabled.
The qt_config_compile_test function is extended with an extra argument
since it's required to pass custom cmake flags to the ld-related test.
Pick-to: 6.2
Change-Id: I484fcc99e2886952d8b0232f37e4e6a35d072931
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
All repositories define QT_NO_INTERNAL_COMPATIBILITY_FUNCTIONS by now,
and we can remove QtCompatibilityHelpers.cmake altogether.
Change-Id: I4d8104246e96a4514d5651c104607d651d208d95
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This proposal collects all the resource objects to the qt-specific
property of the static libraries. This is done to avoid littering
of other static libraries and put resource object files to the
source part of the linker line when linking the end-point
executable.
The way we link object resource libraries is changed back to the
target_link_libraries approach as we may omit using finalizers
with linkers other than ld. Users may enforce finalizers by calling
the qt6_enable_resource_objects_finalizer_mode function if need.
Refactor tests related to the static resources.
Amends ddaa7150d8
Task-number: QTBUG-93002
Change-Id: I74135e291cd82fb54d1b284b4b4a1e002b1fef98
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Only use plugin finalizer mode if qt_finalize_target is called at the
end of the user project (which we can't really check, the user has to
ensure that) or when qt_finalize_target is automatically defer-called
by CMake 3.19+ (which is done by qt_add_executable).
This removes the previous behavior of using the finalizer mode if
qt_import_plugins is called. Instead the old regular mode is used
if the above preconditions are not met.
The removed behavior had ordering issues if qt_import_plugins was called
before target_link_libraries. The dependency walking would be done
before Qt dependencies were added and thus no plugins would be
linked.
Amends 6fcc272ac9
Task-number: QTBUG-80863
Task-number: QTBUG-92933
Task-number: QTBUG-94030
Change-Id: I78702b653a35596f5581c2f4282b2336f0124e60
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
It is now possible to call qt_add_big_resources with multiple .qrc files
that are in different directories but have the same file name.
Before, this resulted in target name conflict errors.
Pick-to: 6.1
Fixes: QTBUG-93230
Change-Id: Ic3d9d6974a107163aeb7ada0b6f1fa113fb18de0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The qt6_add_big_resources command was dysfunctional whenever AUTOMOC was
enabled for a target.
We passed multiple object files with the --temp argument of the second
pass of rcc. We must pass exactly one. The spurious object file was the
one that's created by AUTOMOC. Turn off all of AUTOGEN for the C++
source file that's generated in the first pass of rcc.
Enable AUTOMOC for tests/auto/cmake/test_add_big_resource to cover this
situation.
Pick-to: 6.1
Fixes: QTBUG-85051
Change-Id: I6d2ce4953297db0751913456db0a4a126fe33f14
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's very likely that we'll have to run certain finalizer code for
targets other than executables.
Rename qt_finalize_executable to _qt_internal_finalize_executable so
it's internal.
Introduce a new function qt_finalize_target which will call the above
internal one when the target is an executable.
This should future proof the API so we have a hook to call code for
any user CMake project that intends to use Qt CMake API.
Change-Id: I03f6f4dcba22461351c247a20241ca7de1a59c1d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Allow linking all plugin initializer object libraries directly
into the final target (executable or shared library).
The finalizer mode is triggered when the project adds a call
to qt_import_plugins, as well when the project has an explicit
call to qt_finalize_executable or when it is defer called by
CMake 3.19+.
Otherwise the old non-finalizer mode is used, where each plugin
initializer object library is propagated via the usage
requirements of its associated module.
A user can explicitly opt in or out of the new mode by calling
qt_enable_import_plugins_finalizer_mode(target TRUE/FALSE)
The implementation, at configure time, recursively collects all
dependencies of the target to extract a list of used Qt modules.
From each module we extract its list of associated plugins and
their genex conditions. These genexes are used to conditionally
link the plugins and the initializers.
Renamed QT_PLUGINS property to _qt_plugins, so we can safely query the
property even on INTERFACE libraries with lower CMake versions.
QT_PLUGINS is kept for backwards compatibility with projects already
using it, but should be removed in Qt 7.
The upside of the finalizer mode is that it avoids creating link
cycles (e.g. Gui -> SvgPlugin -> Gui case) which causes CMake to
duplicate the library on the link line, slowing down link time as well
as possibly breaking link order dependencies.
The downside is that finalizer mode can't cope with generator
expressions at the moment. So if a Qt module target is wrapped in a
generator expression, it's plugins will not be detected and thus
linked.
Task-number: QTBUG-80863
Task-number: QTBUG-92933
Change-Id: Ic40c8ae5807a154ed18fcac18b25f00864c8f143
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Now that we run tests for static Qt builds in the CI, it makes sense
to restore the CMake build tests that check that static plugin
importing works correctly.
Resurrect the previously commented out test_import_plugins project and
port the mockplugins qmake projects to CMake.
mockplugins is a CMake project that uses the internal Qt CMake API to
build and install some Qt modules and plugins.
test_import_plugins depends on that test (via a CMake fixture) to
build public projects that use those plugins.
The installation of the mockplugins modules pollutes the Qt install
prefix, but in the CI that only happens on the test VM, which means
the release packages are not affected.
Locally on a developer machine the Qt install path will be polluted,
but it's not that much of a big deal. We could try and address that in
a future change by using the QT_ADDITIONAL_PACKAGES_PREFIX_PATH
functionality added for Conan to allow the installation of Qt packages
into a non-standard prefix.
Task-number: QTBUG-87580
Task-number: QTBUG-92933
Change-Id: I0841064a60a5ffba5118640d3197527a38ba6c30
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The Qt CMake packages are not installed yet, so the CMake build
projects can't find Qt and fail to configure.
Skip the CMake build tests in a prefix in-tree configuration and issue
a warning for informational purposes.
Change-Id: Ie5cb5b9f6f1d8ec258b70528680e31c711c20f85
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
DEFAULT_IF needs to be true so that in a static build the
built plugin is automatically linked into the test executable
using the special static plugin per-repo behavior in
qt_internal_add_executable.
The QtPostProcess routines are not executed for this test project
because we don't use qt_build_repo. This means that no
QtFooPluginCMakeConfig.cmake file is generated and thus there's no
point in using qt6_import_plugins because the pulic plugin genexes
won't know about this target anyway.
Explicitly set the CLASS_NAME so that the name expected by the
Q_IMPORT_PLUGIN macro matches the name of the plugin instance that moc
generates in QT_MOC_EXPORT_PLUGIN.
Amends 22e967c304
Task-number: QTBUG-87580
Task-number: QTBUG-90341
Pick-to: 6.1 6.0
Change-Id: I5ef361e7e2cebc46b35310c679f15c84cd61b4a5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Don't call pre routine function in qAddPreRoutine if
the qt_call_pre_routines is not called
Pick-to: 6.1 6.0
Task-number: QTBUG-90341
Change-Id: I0ee70561dc57b857f8b3b1cf42c9dfe0cf45bd49
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The testcase relied on having optional packages, and that the last
package in that list was found. Otherwise the version numbers of
the found modules were not set.
Change-Id: I76743fd029d6eed2f4b347280591e6fdaed19053
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The test follows up the discussion about tests related to the static
plugin resources:
https://codereview.qt-project.org/c/qt/qtbase/+/341203/6/tests/auto/other/init_resources_static_plugin/CMakeLists.txt#1
It emulates the static plugin that contains resource files. Since the
test already exposed few issues related to the resource object linking
it makes sense to have it in test set.
Change-Id: I62621c2db1eae6ae5842ba52035774a662d93423
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QT_TESTCASE_BUILDDIR was implicitly defined by Qt::Test target for
library users in Qt5. By default, this definition will point to
CMAKE_CURRENT_BINARY_DIR. This logic works similarly to qmake logic.
From user's perspective it might be useful to not rely on standard
search paths, but specify own. This can be done by setting the
QT_TESTCASE_BUILDDIR property for the user's target. CMake will
substute the value of the QT_TESTCASE_BUILDDIR property into the
QT_TESTCASE_BUILDDIR definition.
The implicit QT_TESTCASE_SOURCEDIR also seems to be useful. According
to the current logic, it points to CMAKE_CURRENT_SOURCE_DIR.
Fixes: QTBUG-92079
Change-Id: I8a9065f08e859c713b3c8cc08142a9ced0677770
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
test_QFINDTESTDATA builds the project in the source tree, this is
necessary because the test requires relative paths to the source file
names. This function could be useful for other tests, so it makes sense
to extend the _qt_internal_test_expect_pass/fail macros to support
build in the source tree.
Note that, the SIMULATE_IN_SOURCE argument doesn't build the test in
the existing source tree, but copies source files to the build tree
first to do not litter the source directory.
Change-Id: I16e790d74be2a0c5ca0593e0f88580dbe09882b9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
There was a recent behavior change where the public CMake API
qt_add_plugin API took into account the value of BUILD_SHARED_LIBS
to decide whether the plugin should be a static or shared library.
Instead, use the following new behavior
- If no explicit option STATIC / SHARED option is passed, default to
whatever flavor Qt was built as.
Aka if Qt was configured with -shared, qt_add_plugin defaults
to creating shared plugins. If it's a -static Qt, create static
plugins.
- If an explicit STATIC / SHARED option is set, override the default
computed value with the given value.
As a result BUILD_SHARED_LIBS does not affect Qt plugins anymore. This
is more in line with Qt expectations.
Add SHARED as a new valid option to pass to qt_add_plugin (it wasn't
before).
Add tests to check for the above behavior.
Amends aa4a1006cb
Pick-to: 6.1
Fixes: QTBUG-92361
Task-number: QTBUG-88763
Change-Id: Iae806024ddd5cf10cfe58ddbcebd2818084b0bd7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add new configure option -make minimal-static-tests and CMake option
QT_BUILD_MINIMAL_STATIC_TESTS. In conjunction with QT_BUILD_TESTS
it will enable building a minimal subset of tests when targeting
a static desktop Qt build.
In qtbase the minimal subset includes all the auto tests of testlib,
tools, corelib and cmake. In particular this will also do cmake build
tests and qmake build tests (tst_qmake)
Adjust CI instructions to enable building a minimal subset of static
tests when a platform configuration is tagged with the
MinimalStaticTests feature.
Fix and skip a few tests that were failing.
Pick-to: 6.1
Task-number: QTBUG-87580
Task-number: QTBUG-91869
Change-Id: I1fc311b8d5e743ccf05047fb9a7fdb813a645206
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The _qt_internal_test_expect_fail macro fails when the test fails
during the configuration step. Rename this macro to
_qt_internal_test_expect_build_fail and add
the _qt_internal_test_expect_fail macro that expects inverted test
result.
Change-Id: I4635e99152f7a32f5c48202e84fec59800453d34
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add INTERFACE_COMPILE_DEFINITIONS of Qt6::Core to generated rcc object
libraries. This propagates QT_NAMESPACE definition to the object
library.
Fixes: QTBUG-85620
Change-Id: I252d1aaee7b19a49bc321fdd271a5d85a34bf67f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Remove the qmake project files for most of Qt.
Leave the qmake project files for examples, because we still test those
in the CI to ensure qmake does not regress.
Also leave the qmake project files for utils and other minor parts that
lack CMake project files.
Task-number: QTBUG-88742
Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Complete search and replace of QtTest and QtTest/QtTest with QTest, as
QtTest includes the whole module. Replace all such instances with
correct header includes. See Jira task for more discussion.
Fixes: QTBUG-88831
Change-Id: I981cfae18a1cabcabcabee376016b086d9d01f44
Pick-to: 6.0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
test_QFINDTESTDATA is a test which is built and run in the source
tree. It tests usage of relative paths of the Ninja generator, which
only occurs when building in the source tree, so this test cannot
be done outside of the source tree.
Developer's expectation is, however, that an out-of-source build
does not change the source tree. Having "git status" showing
differences after running the tests is irritating. This patch removes
the in-source build files after executing the test.
Change-Id: Ia9fd368c9d54b97a415b63254b45e17bc95ecf45
Reviewed-by: Craig Scott <craig.scott@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add handling of -binary flag in qt6_add_resources for generated
resource file variant.
If -binary argument is provided in OPTIONS section of
qt6_add_resources function, it will be passed to rcc as argument.
File path to output .rcc could be additionally specified by
DESTINATION argument. Extra target generated_<resource_filename>
will be added to project's 'all' set.
Implement tests for new functionality.
Fixes: QTBUG-87644
Change-Id: Id1313da499d86f82859d1757c3cfae2d84e894d4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This time based on grepping to also include documentation, tests and
examples previously missed by the automatic tool.
Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Add some missing versionless functions.
Rename some functions that are not meant to be public API, and their
usages.
Task-number: QTBUG-86827
Change-Id: Ifb66c04cd7598d83fe80c01a92ab2d269ebaf396
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Qt6 package was not found the tests were configured in-tree as opposed
to standalone tests.
Use the same trick we do for building examples in-tree.
Specify the path to the build tree packages, and don't create targets.
Amends 96e3ee0659
Change-Id: Ia60de416ce0afff5bd40be8c0c6e3c7898fd7ebf
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
The tests/auto/cmake project can be configured separately as a
standalone project with qt-cmake, or as part of the overall qtbase
standalone tests.
To do that a bunch of things were done
- Ported all Qt5 strings to Qt6
- Replaced in all projects the use of add_definitions and
include_directories with a target based approach, except for 2 tests
where we check that the old-style approach works, otherwise the
tests would file
- Removed some (possibly unneeded) EGL / OpenGL tests
- Fixed some C++ code
- Added setup code to tests/auto/cmake/CMakeLists.txt to figure out
which modules are available and should be tested
- Fixed Qt6CTestMacros.cmake to be loaded by Qt6Core
- Removed the CMake tests to not be run in qmake builds of Qt because
they would fail anyway
- Enabled the CMake tests to be part of standalone tests
- Disabled auto-passing of the C and CXX compiler cache vars when
cross-compiling so that the tests can somewhat pass on boot2qt.
This is the issue we encountered in
e2b2cd9397
- Ultimately disabled tests for boot2qt, because the -rpath-link
flag is not generated by CMake for some reason.
- Added code to setup the environment when running an executable that
was built as part of the test, so that the proper Qt libraries are
found. This handles both the standalone tests case and separate
project case.
The remaining unported tests are test_import_plugins which requires
quite a bit of work to get some modules and plugins built that were
done as part of the qmake .pro files, test_plugins that checks
some Network plugins which I'm not sure about, and
test_add_big_resource which doesn't work with namespaced builds
and there's no good way of detecting those at the moment either.
Change-Id: Ic8809c72817d1db81af6c6014c11df6473ad8c75
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
[ChangeLog][General] The QtOpenglExtensions module has been
discontinued. It provided only convenience functionality for certain
direct OpenGL usage. With the new RHI graphics API abstraction, that
is no longer a primary use case. Applications that still need to
access that API have a number of alternative options, including
QOpenGLExtraFunctions.
Fixes: QTBUG-84085
Change-Id: I272af61c69ebcec207b576d67d08b59623d485ec
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
The QT_OPENGL_ES* macros are leftovers from an earlier,
ad hoc configuration system, which has since been
replaced by QT_CONFIG. To clean things up in Qt 6,
we use the new way instead.
Task-number: QTBUG-83467
Change-Id: I578dc7695bff9d5ee303b22e44f60fee22fe0c28
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
qt5_use_modules has been deprecated in 2013 (commit d9ea4bb144)
and removed for the first time in 2018, but then brought back - see
discussion in https://lists.qt-project.org/pipermail/development/2018-June/032837.html .
Anyhow, I think we can finally put it to a rest in Qt 6.
Change-Id: I770f7e93406ad68535d1d90e4a3bacfb920e2d5a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This commit adds transitive dependencies to the plugins, so that a
sane set of default plugins get auto-imported when linking against a
module. It also provides a new function, qt5_import_plugins(), which
allows you to override the set of plugins that get imported. The decision
of whether or not to import a specific plugin is based on several custom
target properties and a very clever generator expression.
Note that this change only imports plugins on static Qt builds. It
does nothing on shared Qt builds, as the shared libraries already have
their own plugin import mechanism.
[ChangeLog][CMake] Added ability to auto-import non-qml plugins on
CMake builds
Task-number: QTBUG-38913
Task-number: QTBUG-76562
Change-Id: I2d6c8908b521cf6ba1ebbbc33a87cb7ddd9935cf
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
qt5_add_big_resources is only available if using CMake 3.9 and later.
This amends cdccd0222b.
Task-number: QTBUG-55680
Task-number: QTBUG-75806
Change-Id: Ibba7af6ee7edfb226368937d543b7ec5cc93eb16
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
