Since we add 3rdparty libraries to the set of the Qt modules, they are
treated as the Qt modules by the depenedcy helper as well. So give them
_qt_module_interface_name to fix dependency helper.
Amends 425ff34aa1
Change-Id: I5898c1c90156de1878aeeef5a0924349b44c50fa
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We need to export the Private targets of the internal modules to keep
compatibility with existing internal module users across repositories.
Amends 425ff34aa1
Fixes: QTBUG-93943
Change-Id: I10234cec1eb618b69d041f80fbe29620a4e307b9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When dealing with a universal build of Qt, we would end up
using the QT_ARCH as the architecture for user projects,
but this architecture is always the primary one that Qt
was configured with.
Instead of relying on QT_ARCH, we start writing QT_ARCHS
(plural) to qconfig.pri, based on CMAKE_OSX_ARCHITECTURES,
and then use that to initialize QMAKE_APPLE_DEVICE_ARCHS.
We then resolve the active arch using uname -m, matching
what CMake does.
We still feed all the available architectures to the
Makefile or Xcode project, so that the user can build
for any of the available architectures without needing
a reconfigure.
Fixes: QTBUG-93760
Change-Id: I0d338241ba4d944ca36d85371e9c4df7dbc4f269
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
After discussion we decided to opt-out the UNICODE definintion
behavior. To disable UNICODE in user projects the
qt6_disable_unicode_defines function could be used.
Amends 5b64e5950c
[ChangeLog][CMake] Enables the UNICODE and _UNICODE definitions on
WIN32 platforms by default for all cmake projects to reflect the
qmake behavior. Use qt6_disable_unicode_defines function to disable
the default unicode definitions.
Pick-to: 6.1
Fixes: QTBUG-93895
Change-Id: Id70ff7dcf8c74f660ec851f8b950e1e3b94d9fb4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
HEADER_MODULEs use the INTERFACE visibility to link libraries. This
causes a transitional propagating of the Qt-internal compile definitions
and options to the user targets.
This commit avoids an implicit adding of the Qt::PlatformModuleInternal
library to the HEADER_MODULEs and stops propagation of the Qt-internal
compile definitions and options. If module wants the transitional
propagation of some properties, this needs to be done explicitly.
Amends 8b7894cb63
Pick-to: 6.1
Fixes: QTBUG-89951
Change-Id: Ia9cecc38bac98eb5bc6e47d288308b49813ab5ac
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In cmake, targets are used as an entity for modules. This causes a
number of problems when we want to manipulate a module as a separate
entity with properties associated with it.
The _qt_internal_module_interface_name target property is introduced to
represent the module entity. All modules write a name to this property,
which will subsequently expand into the module name matched with
the module name in qmake.
The 'qt_internal_module_info' function is responsible for providing the
correct values for the module properties used when working with a module
target.
Unlike qmake, for internal modules in cmake it is expected that the
Private suffix will be specified explicitly. In case the user wants to
have a different module name, an additional argument
MODULE_INTERFACE_NAME of the qt_internal_add_module function is
introduced.
This also changes the way how target dependencies are collected and
resolved. Since the 'Private' suffix no longer means an unique
identifier of the module 'Private' part, we look for the both Private
and non-Private package names when resolving dependencies.
TODO: This change doesn't affect the existing internal modules, so to
keep compatibility with the existing code the existing internal modules
create 'Private' aliases. The code that provides backward compatibility
must be removed once all internal modules will get the proper names.
Taks-number: QTBUG-87775
Change-Id: Ib4f28341506fb2e73eee960a709e24c42bbcd5ec
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Introduce the concept of repository target sets, which is a named set of
targets within a Qt module repository.
In a Qt repository, a repo target set 'qtfoo' can be defined in the
top-level project file with
qt_internal_define_repo_target_set(qtfoo DEPENDS Bar Baz)
The DEPENDS argument specifies Qt components that need to be
find_package'd when building the targets that belong to qtfoo.
In subdirectory project files, use
qt_internal_include_in_repo_target_set(qtfoo) to mark the file as
belonging to the repo target set.
To build and install a single repo target set, specify
QT_BUILD_SINGLE_REPO_TARGET_SET=qtfoo when configuring the Qt
repository.
Change-Id: Ic9e6213e3225988fd561f315bc857ee44ff17420
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
Instead of compiling the plugin initializers as part of a user
project, pre-compile them as object libraries while building Qt.
The installed object libraries can then be used with
target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>)
so that they are linked into the final executable or shared library
via qt module usage requirement propagation.
This reduces the build times of user projects.
The link line placement of the object files should be correct for all
linux-y linkers because the only dependency for the object files is
Core and the Gui -> plugin -> Gui -> Core cycle does not hamper that
from empirical observations.
As a consequence of the recent change not to link plugin initialization
object files into static libraries, as well not having to compile the
files in user projects, we can get rid of the
_qt_internal_disable_static_default_plugins calls in various places.
A side note.
Consider a user static library (L) that links to a Qt static library
(Gui) which provides plugins (platform plugins).
If there is an executable (E) that links to (L), with no direct
dependency to any other Qt module and the intention is that the
executable will automatically get the platform plugin linked,
then (L) needs to link PUBLIC-ly to (Gui) so that the plugin usage
requirements are propagated successfully.
This is a limitation of using
target_sources(qt_module INTERFACE $<TARGET_OBJECTS:plugin_init>)
which will propagate object files across static libraries only if
qt_module is linked publicly.
One could try to use
target_link_libraries(qt_module
INTERFACE $<TARGET_OBJECTS:plugin_init>)
which preserves the linker arguments across static libs even if
qt_module is linked privately, but unfortunately CMake will lose
dependency information on Core, which means the object files might be
placed in the wrong place on the link line.
As far as I know this is a limitation of CMake that can't be worked
around at the moment.
Note this behavior was present before this change as well.
Task-number: QTBUG-80863
Task-number: QTBUG-92933
Change-Id: Ia99e8aa3d32d6197cacd6162515ac808f2c6c53f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This is to allow other repos like qtdeclarative to more easily pass
through supported arguments to qt_internal_add_module() from their own
functions.
Task-number: QTBUG-88763
Change-Id: I965d593de4c6f9d5295a0d427c32dc3d5b1bb639
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Q_IMPORT_PLUGIN generates a global static symbol that initializes a
plugin. If this symbol is added to a static library and the library
is then linked to an executable, the linker decides that the symbol is
unused (because nothing references it) and discards it.
This means there's no point to compile the Q_IMPORT_PLUGIN containing
files into static libraries.
Change the generator expression we use for plugin propagation via
associated modules to not compile and link the plugin initialization
object file into a static library.
Pick-to: 6.1
Task-number: QTBUG-80863
Change-Id: Ide32c0124c1e313c352a72280ce32ce9fbe8fff1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The option is called QT_CREATE_VERSIONED_HARD_LINK. By default, it
is set to ON. Users can set this option to OFF to disable versioned
hard link.
Pick-to: 6.1
Fixes: QTBUG-93636
Change-Id: I0ffa1ee1c6bae1950df332fcce3152a861b33db0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
There was a D missing, we want to set CMAKE_REQUIRED_LIBRARIES
Pick-to: 6.1
Change-Id: I7a76d60480ef7bff439f298fe85614d3b7e3ae88
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Allow collecting all public dependency CMake targets starting from
a given initial target.
The new mode walks INTERFACE_LINK_LIBRARIES of a shared library
or executable target, as well as the INTERFACE_LINK_LIBRARIES and
LINK_LIBRARIES of a static library target.
Each encountered target (checked with if(TARGET)) is added the output
list.
Note that the private dependencies of a non-static target (like a
shared library or executable) are not walked by the new mode.
Introduce a new function called
__qt_internal_collect_all_target_dependencies which uses the new
mode to collect the full private dependency list of a target.
The final list only contains targets, so no linker flags or file
paths.
This list is useful to do further processing on the targets like
extracting properties from them and running finalizers.
Task-number: QTBUG-92933
Change-Id: I5d96cfa05722d65e2248a344a4f2b0f98a992817
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Needed for the upcoming static plugin mechanism, where we have to
extract the list of Qt module dependencies of a target and then extract
the plugins associated with those modules.
To do that we need to recursively collect the dependencies of a given
target.
Rename the moved functions to contain the __qt_internal prefix.
Also rename the existing QtPublicTargetsHelpers.cmake into
QtPlatformTargetHelpers.cmake to avoid confusion with the newly
introduced QtPublicTargetHelpers.cmake.
Task-number: QTBUG-92933
Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Extract common static plugin handling functionality into a separate
QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package.
Split the code into smaller functions that will be re-used by each
templated QtPlugins.cmake.in file, rather than copy pasting the same
code into each QtFooPlugins.cmake file.
As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake
as public helper files just like QtPublicPluginHelpers.cmake.
This makes it clearer that the functions are available outside
the internal Qt build and also provides a way for not dumping new
helper functions into Qt6CoreMacros.cmake.
Task-number: QTBUG-92933
Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Use paths configured with QT_ADDITIONAL_PACKAGES_PREFIX_PATH
to search also for the tool packages.
Task-number: QTBUG-93565
Pick-to: 6.1
Change-Id: I611b275dd7c4e7ecceb073d16643cd225bbb21d8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Sometimes projects don't follow the standard directory layout, so they
end up copy-pasting the guts of qt_build_repo and adapting that.
Split the macro into smaller ones so it's easier to reuse.
Change-Id: I8cc72ba2a2eaf58afd44950b3ac78378b7b1fdfd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
list(PREPEND) command was added in CMake 3.15+, but so far we claim
support for CMake 3.14 in user projects.
Use set command instead.
This is not the only place where we use list PREPEND in public API,
but it's the first immediate issue that comes up when using CMake
3.14.
Amends 963017f588
Pick-to: 6.1
Change-Id: I7ba4507fc7da2dc550317848751502b8b46c298c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We want standalone tests added by qt_internal_add_test to be built as
universal executables, so we can build them on an intel machine and
run them on an ARM machine.
But CMake build tests will be built on the final machine that runs the
tests and it might lack a universal SDK. That's why they should be
built only targeting the architecture of the machine they're running
on.
Change the generated qt.tooclhain.cmake file to allow opting in or out
of building projects with the same architectures as Qt was configured
with.
Now standalone tests will be multi-arch, but CMake build tests will be
single-arch.
Amends e379147f95
Task-number: QTBUG-85447
Task-number: QTBUG-87580
Task-number: QTBUG-92933
Change-Id: I41ab047983115f84eb2333cc9ac2d19ca08d621f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The -developer-build had not the desired effect anymore.
That argument must not be hidden from the feature logic.
This amends commit d5c3e1336b.
Change-Id: I96562ea2df43ba7de002e705f28c7cc7edb4a589
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Let -developer-build, -cmake-file-api set up the CMake File API query,
so that the build can be loaded directly into IDE's like Qt Creator.
[ChangeLog][Build System] configure -developer-build now sets up
the CMake File API query, so that a build can be loaded without
reconfiguration into Qt Creator and other IDE's. Pass
-developer-build -no-cmake-file-api to configure to disable this.
Fixes: QTBUG-89487
Change-Id: I69199b8f96da02e42e5610aa6f49881c1582f7da
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
BrotliCommon is a dependency of BrotliDec and BrotliEnc.
amends 5d2da76c1e
Pick-to: 6.1
Change-Id: I7741d417e95737f8caacd01962985a27dbb7514c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Passing this configure argument will generate a JSON file that contains
information about configure options and features.
This file is used by Qt's conan recipes.
Fixes: QTBUG-92082
Change-Id: I2057ec8cbdb0a1ea198d7eeacb45f65bfa862d8a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
file(REAL_PATH) was introduced in CMake 3.19.
Use get_file_name_component(... REALPATH) instead that is available in
older CMake versions.
This amends commit b226e99c71.
Pick-to: 6.1
Change-Id: Ibb28ef757228e1a1176ff70c3ec57b7ca751a636
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The libraries already contain the ABI suffix, and the .prl files should
too. This is a requirement for ABI-stitching of Qt Android builds.
Fixes: QTBUG-90023
Change-Id: Ib2a7b3119ace14c8542242fc45f42648840d053a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Clarify that OUT_FILE is not the final .prl anymore and where we get the
path of the final .prl from.
Change-Id: I4563c6ef1026bc0646e3ac9ab2fac49e426ca07f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
QT_TOOL_PATH_SETUP_COMMAND is used in COMMAND list when call
add_custom_command/add_custom_target. This is necessary to setup
the necessary environment for the tool to run correctly. This approach
is weak according to CMake documentation:
"If more than one COMMAND is specified they will be executed in
order, but not necessarily composed into a stateful shell or
batch script."
This change introduces the _qt_internal_wrap_tool_command function
that uses a wrapping script that setups necessary environment for
the tool and runs it in a single shell.
The script is generated by the _qt_generate_tool_command_wrapper
function.
Change-Id: Id5270b91619b607a0c1e3a19b8c706edec43f388
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The qt_internal_module_info function suppose to provide the information
only about the Qt modules. Avoid using it for the tool and extra
package dependencies, since some targets do not always exist, when
function is called.
Add the qt_internal_qtfy_target function to make the prefixed target
names.
Change-Id: Ifa8c61064d9c6c430889f00a4ead304029da711b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
... and configuring another repo using qt-configure-module.
It's possible to configure a top-level Qt with a subset of repos and
then afterwards configure additional repos with qt-configure-module.
We didn't define QT_REPO_DEPENDENCIES in that case, which caused all
plugin config files to be loaded on reconfiguration, thus causing
duplicate target errors.
Move the QT_SUPERBUILD check to be done every time in
QtBuildInternals.cmake rather than when configuring qtbase/qt5.
Amends 98e8180e56
Pick-to: 6.1
Fixes: QTBUG-86670
Fixes: QTBUG-91887
Fixes: QTBUG-92578
Change-Id: I975835ffa02f702799a3c9f68a5e059d2763a951
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Packagers usually build Qt per repo, but the documentation must be built
from the full Qt source archive to ensure that inter-repo links are set
up correctly. When building the documentation, it's desirable to avoid
building tools and re-use to tools of an existing Qt build.
One now can do a documentation-only build by configuring Qt like this:
cmake /path/to/Qt/source -GNinja \
-DQT_HOST_PATH=/path/to/Qt/installation
and build the documentation with
ninja docs
To avoid building tools, this patch removes the DEPENDS arguments from
some add_custom_target calls in QtDocsHelpers.cmake and makes another
one conditional. The removed dependencies are added at the end of
qt_internal_add_docs. Adding of tool dependencies is not done if
QT_HOST_PATH is set.
Fixes: QTBUG-88441
Change-Id: I3b7a908e22d252d2edcdc1dd522a78b8ad6c487e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's necessary to have versioned alias of the Platform target to use
versioned target in the installable cmake files.
Pick-to: 6.1
Change-Id: I79286e1c0642068bdfa5d24c1087ee0c39e48f1a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When configuring a Qt module with qt-configure-module, we want to use
the same CMake generator that was used for building qtbase.
That generator is encoded in qt-cmake-private. But qt-configure-module
overrides the generator after trying to detect what generator should be
used. That auto-detection is only useful for qtbase-builds and top-level
builds. Turn it off for repo builds other than qtbase.
Pick-to: 6.1
Fixes: QTBUG-91405
Change-Id: I07efb4afb51ba69d2f5467d272118fa51637ab54
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's important for conan CI builds where the correct installation
location of Qt should be used when configuring standalone tests.
Task-number: QTBUG-93037
Change-Id: I2465a439aea6826dedfb3217d1c909ad639d4ac0
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Previously, in a top-level build we always generated the final prl
file somewhere under QT_BUILD_DIR (which is qtbase_build_dir). After
each repo was processed by QtPostProcess.cmake, we installed the prl
files found in PROJECT_BINARY_DIR.
For qtquickcontrols2 this meant that qml plugin prl files were placed
under qtbase/qml, but we tried installing the prl files from
qtquickcontrols2/qml, which didn't have any prl files.
In a static Qt build, qmake's qt.prf calls qmlimportscanner to
identify which plugins should be linked to the executable. This worked
fine because the plugin .pri files were installed correctly.
None of the qml plugin library dependencies were linked in though.
This is supposed to happen in qmake's C++ code where it tries to
find the associated prl file of a linked library in order to extract
all its dependencies. Because no prl file was found, linking failed
with multiple undefined symbols.
Fix this by installing the prl files from QT_BUILD_DIR rather than
PROJECT_BINARY_DIR.
Note that this will create multiple install rules for certain files,
but it's harmless. An example is imageformats.
We process qtbase plugins, see qjpeg, issue an install rule from under
the qtbase/plugins/imageformats folder. We then process
qtimageformats plugins, see webp, issue another install rule from
under qtbase/plugins/imageformats.
The first install rule will install both qjpeg and qwebp, the second
install rule will merely say all plugins are up-to-date.
Pick-to: 6.1 6.0
Change-Id: I8a4bb67bfafc1d016eab62f4fe66b6ba378ceeb2
Fixes: QTBUG-93021
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Passing Android-related variables to the initial CMake call would have
no effect if no (or an empty) value of CMAKE_TOOLCHAIN_FILE was
specified. To alleviate user confusion, yield an error if an Android
build was apparantly requested, but the toolchain file is missing.
Change-Id: I28ec94eabe436d4b9b410b48c7cad1b48d3e1bec
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before, we relied on the deprecated "ndk-bundle" subdirectory being
present in the SDK root. Now, we choose the NDK with the latest version
in the SDK's ndk subdirectory.
Pick-to: 6.1
Fixes: QTBUG-87579
Change-Id: I37a9e03184f4518b4074d55375af08209591de94
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
When ANDROID_NDK_ROOT is explicitly set by the user, there's no point in
detecting the NDK. The detection had no effect, because the already set
ANDROID_NDK_ROOT variable would not be overwritten by our set call.
Fix the condition of the check: There is no CMAKE_ANDROID_NDK_ROOT
variable.
Pick-to: 6.1
Change-Id: I8f0d4f2a1a67445f67a79c7d2d0932099828b05e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's needed in qtconnectivity, but currently the
qt_disable_apple_app_extension_api_only function is defined in
QtInternalTargets.cmake which is loaded only in qtbase.
Move the function to cmake/QtTargetHelpers.cmake.
Amends e189126f1a
Pick-to: 6.1
Change-Id: Ia2470e48a91385239394368780f5bbb223000113
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
When cross compiling from a case sensitive file system, casing
matters, and mingw headers and import libraries consistently
use lowercase.
This was uncovered by d385158d5213ef568b7629e2aa4a818016bbffac;
prior to that, the schannel TLS plugin didn't end up built (at
least when cross compiling).
Fix other similar cases that can be found by grepping the repo.
Change-Id: Ia696e17b7aaa979d7b7f5b0801383f338a8b585b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Currently in order to compile a Qt6 test standalone one needs to use
the qt-cmake-standalone-test script which will load the
Qt6BuildInternals/QtStandaloneTestTemplateProject/CMakeLists.txt project
with the current test source directory to create a complete CMake project.
This commit will allow a test to have these lines at top:
cmake_minimum_required(VERSION 3.16)
if (NOT QT_BUILD_STANDALONE_TESTS AND NOT QT_BUILDING_QT)
project(a_qt_test LANGUAGES C CXX ASM)
find_package(Qt6BuildInternals COMPONENTS STANDALONE_TEST)
endif()
and be standalone and work with any IDE capable of loading CMake projects.
Fixes: QTCREATORBUG-25389
Pick-to: 6.1
Change-Id: If3f878b7e560a8bfbb604a8f1aa30b7962742e66
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Certain repositories like qtsvg, qtimageformats and qtvirtualkyboard
build plugins associated with Qt modules from other repositories
(qtsvg's QSvgPlugin associated to qtbase's QtGui).
When configuring in-tree tests in the same build folder as the
repository, the test executables would not automatically link to these
plugins.
Fix this by recording the existence of such plugins in a separate
property of the associated Qt module and only link them when both the
test executable and plugin are from the same project (their
PROJECT_NAME coincides).
This is in addition to linking the plugins associated with the
module where both are built in the same repository.
The logic is a bit tricky and ensures that plugins are not
accidentally initialized twice, so that in-tree tests work for both
top-level and per-repo builds.
As a drive-by, added a TODO explaining why in-tree tests that need to
link to static QML plugins won't work (somewhat unrelated to this
change).
Amends 734d2cdbc4ff6db6b3df8fffbb23dbbb565c076b
Amends b1fcdad9c9b9ad2bddd00f7301c8dd1159d523c2
Pick-to: 6.1
Task-number: QTBUG-87580
Change-Id: I3e1ff8166864f92dea931ec2ea34b6f56b4eec60
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add SOLARIS cmake platform definition.
Add settings for QT_DEFAULT_MKSPEC so that qplatformdefs.h can be found.
Solaris has its gssapi symbols in libgss.
Solaris supports @ORIGIN.
Solaris ld does not support --dynamic-list needed for reduce relocations.
Make solaris fail the reduce relocation test.
getauxval is specific to GNU libc and some other libc implementations on
Linux but sys/auxv.h is not. The bootstrap uses sys/aux.h as the only
indication for getauxval. This breaks builds on Solaris, so only make
sys/auxv.h an indicator for getauxval on linux or glibc based systems.
Solaris uses X11 so add it to the X11_SUPPORTED list.
Solaris network libraries for sockets etc are in socket and nsl.
ifreq does not have a member ifr_ifindex on Solaris, it uses
ifr_index. Add test to check if ifr_index is a member of ifreq.
The first struct in the in_addr union on solaris is defined as four
uint8_t, therefore four arguments are needed for its initializer list.
Change-Id: Ieed4c1bbac8559a7ae1db9c4e1e91f609f150270
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
