Commit Graph

1290 Commits

Author SHA1 Message Date
Alexey Edelev
425ff34aa1 Merge main and private targets of the internal modules
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>
2021-05-20 19:40:45 +02:00
Joerg Bornemann
4b09522c23 Add support for building and installing repo target sets
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>
2021-05-20 12:08:33 +02:00
Alexandru Croitor
6fcc272ac9 CMake: Introduce finalizer mode handling of static plugins
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>
2021-05-20 00:55:46 +02:00
Alexandru Croitor
91c65dd80c CMake: Build plugin initializers as object libs
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>
2021-05-18 22:03:46 +02:00
Tor Arne Vestbø
f2d26f95fe cmake: Add repository name to test labels for qt5 builds
Change-Id: Icb23f2ea885f6d21bef80c587a431f7e9349f21b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-18 21:07:51 +02:00
Craig Scott
21607d5db5 CMake: Provide supported qt_internal_add_module() args via a function
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>
2021-05-18 23:59:24 +10:00
Alexandru Croitor
5268edf581 CMake: Don't do plugin initialization for static libraries
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>
2021-05-17 19:11:10 +02:00
Lorn Potter
7c4363ba4c wasm: make sure bind is compiler argument
Fixes: QTBUG-93713
Change-Id: I027caccb5c37bab529c80efac0b575a363be5f89
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-14 13:45:28 +10:00
Li Xinwei
320c282488 CMake: add an option to enable or disable versioned hard link
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>
2021-05-13 05:04:57 +08:00
John Zimmermann
224fccdaec Fix typo in FindWrapAtomic.cmake
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>
2021-05-12 14:49:45 +02:00
Alexandru Croitor
8fc3fcf425 CMake: Add 'collect_targets' mode to __qt_internal_walk_libs
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>
2021-05-11 18:57:17 +02:00
Alexandru Croitor
471ff20f33 CMake: Make qt_internal_walk_libs available in public projects
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>
2021-05-11 18:57:17 +02:00
Alexandru Croitor
b70a4da4f7 CMake: Hide qt plugin static import source files in a dot folder
To keep the build directory tidier.

Task-number: QTBUG-92933
Change-Id: I27213185a78b292bda7ae34bbc8161d4b5583872
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2021-05-11 18:57:17 +02:00
Alexandru Croitor
b104bedea1 CMake: Refactor handling of static plugins
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>
2021-05-11 18:57:17 +02:00
Samuli Piippo
60c87c6801 CMake: use additional search paths also for tool package
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>
2021-05-10 17:52:23 +03:00
Alexandru Croitor
326c7ecdfd CMake: Split qt_repo_build() into reusable macros
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>
2021-05-10 16:52:23 +02:00
Alexandru Croitor
c457e65bf4 CMake: Don't use list(PREPEND) in qt.toolchain.cmake
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>
2021-05-10 11:28:52 +02:00
Alexandru Croitor
0d8eb8a5ab CMake: Don't build cmake build tests as macOS universal
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>
2021-05-10 11:20:44 +02:00
Joerg Bornemann
23e6eb53f3 Fix developer build
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>
2021-05-10 10:08:53 +02:00
Kai Köhne
d5c3e1336b Allow to load -developer-build without configurations into an IDE
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>
2021-05-07 21:06:58 +02:00
Li Xinwei
d104d510ea CMake: fix build with static Brotli
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>
2021-05-07 02:06:44 +08:00
Simo Fält
3969ef40cc Add instructions for Windows 10 on Arm config
Task-number: QTQAINFRA-3966
Change-Id: Ib8ac80a5b8aa5c88d9e5d0eaad9ba550cc2442f8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Fathi Boudra
2021-05-05 16:28:27 +03:00
Joerg Bornemann
3886db82c6 Add -write-options-for-conan configure argument
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>
2021-05-05 16:28:27 +03:00
Joerg Bornemann
33ac3cf766 Fix Windows build with CMake < 3.19
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>
2021-05-05 09:41:18 +02:00
Joerg Bornemann
d41ef4f741 Add ABI suffix to .prl files for Android
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>
2021-05-03 13:33:43 +02:00
Joerg Bornemann
b0e96ee181 Update the comment in QtFinishPrlFile.cmake
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>
2021-05-03 13:33:43 +02:00
Thiago Macieira
d08d456844 cmake: FreeBSD has DF_ORIGIN support
Pick-to: 6.1 6.0
Change-Id: I755911ae7d0341f49039fffd167afce7fe6b2b38
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-05-01 16:02:31 -07:00
Alexey Edelev
b3f9c2b3d1 Add _qt_internal_wrap_tool_command to replace QT_TOOL_PATH_SETUP_COMMAND
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>
2021-04-30 23:11:29 +02:00
Alexey Edelev
5ae7527411 Do not use qt_internal_module_info for non-module targets
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>
2021-04-30 14:55:11 +02:00
Alexandru Croitor
e1c1558218 CMake: Fix reconfiguration when using a static top-level build
... 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>
2021-04-29 23:42:40 +02:00
Joerg Bornemann
582fdf06d1 Make a documentation-only build possible
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>
2021-04-29 13:05:16 +02:00
Alexey Edelev
8f238788de Add versioned alias for the Platform target
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>
2021-04-27 21:33:48 +02:00
Lorn Potter
cdad78a4a4 wasm: do not set autodetect wasm true until we actually detect
Change-Id: Ib6bdd3d5ed7dab108b636284ee564d14dbc2d5c8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2021-04-27 09:49:34 +10:00
Joerg Bornemann
52077d4f01 Inhibit CMake generator detection for qt-configure-module
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>
2021-04-26 23:11:28 +02:00
Alexandru Croitor
adf29329ea CMake: Make qt-internal-configure-tests relocatable
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>
2021-04-26 23:11:28 +02:00
Alexandru Croitor
31ee3c84a7 CMake: Install prl files from all repo build dirs in a top-level build
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>
2021-04-26 19:35:55 +02:00
Joerg Bornemann
f1c37ead59 Error out if requesting Android build without toolchain file
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>
2021-04-23 16:50:55 +02:00
Joerg Bornemann
74310cb36f Android: Choose latest version when autodetecting the NDK
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>
2021-04-23 16:50:55 +02:00
Joerg Bornemann
ff7f32f26b Android: Do not auto-detect NDK if ANDROID_NDK_ROOT is set
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>
2021-04-23 16:50:55 +02:00
Alexandru Croitor
393f45de90 CMake: Allow enabling Apple app extension API in other repos
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>
2021-04-23 16:50:55 +02:00
Martin Storsjö
236ae73ed8 Lowercase system includes and lib names for Windows, fix cross compiling
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>
2021-04-23 14:31:04 +03:00
Cristian Adam
0a1256a52d CMake: Allow usage of QtStandaloneTestTemplateProject as package component
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>
2021-04-23 13:31:04 +02:00
Alexandru Croitor
6969496e00 CMake: Fix auto-linking of static plugins for non-QML in-tree tests
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>
2021-04-22 16:15:41 +02:00
Niclas Rosenvik
fadd87ed15 Add Solaris support in cmake build
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>
2021-04-21 20:57:04 +00:00
Alexandru Croitor
be1ee03a0f CMake: Fix auto-linking of static plugins in standalone tests
The change introduced in 98e8180e56
fixes reconfiguration issues for repositories that provide plugins
associated with modules from a different repository
(QSvgPlugin -> QtGui -> qtbase).

It does so by only loading the public Plugin CMake packages of
dependent repositories.

For executables / tests that are built as part of the current
repository, plugins are linked via a different simplified mechanism in
qt_add_internal_plugin and qt_internal_add_plugin in order to prevent
exporting link cycles between plugins and Qt modules.

This works for the majority of in-tree tests, but unfortunately breaks
static standalone tests.

For example in qtbase neither mechanism will link plugins to the
standalone tests:

 - qtbase has no repo dependencies, so the first mechanism (loading of
   public plugin packages) is skipped because we assume we are merely
   reconfiguring the main build of qtbase and we don't want to
   accidentally create duplicate plugin targets

 - because a standalone test configuration does not call
   qt_internal_add_plugin, no association is done between qt plugin
   and module and thus all tests (qt_internal_add_test ->
   qt_internal_add_executable) don't get the simplified plugin
   linking

Fix this by allowing loading of the public CMake plugin packages when
doing standalone tests. It should be safe to do so because we don't
build any plugins in this case, only tests.

Amends 98e8180e56

Pick-to: 6.1
Task-number: QTBUG-87580
Change-Id: I690a0366c73a24e7f49c65ed13cd70362c273d81
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-21 15:21:08 +02:00
Li Xinwei
c7a27678d6 MSVC: define _CRT_SECURE_NO_WARNINGS for all internal CMake targets
In commit 013abe3206, I add
_CRT_SECURE_NO_WARNINGS definition for all Qt internal module targets,
to suppress MSVC warnings like:
warning C4996: 'strncpy': This function or variable may be unsafe.

However, when compiling some internal tools, such as qmake and qdoc,
such warnings also exist. To suppress this kind of warning entirely,
_CRT_SECURE_NO_WARNINGS definition should be added for all Qt internal
targets when using MSVC compiler.

Pick-to: 6.1
Change-Id: I9c37b20672f9d0f470e3e9ea847e5221f43bfc04
Reviewed-by: Yuhang Zhao <2546789017@qq.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
2021-04-20 21:19:32 +08:00
Li Xinwei
5d2da76c1e make FindWrapBrotli.cmake not depend on vcpkg or PkgConfig
Currently, FindWrapBrotli.cmake depends on vcpkg or PkgConfig. But for
users who build Brotli by themselves and don't have vcpkg or PkgConfig,
the Brotli cannot be found.

As a reference, I use following CMake commands to build Brotli:
cmake path/to/Brotli/source -G"Ninja Multi-Config"
-DCMAKE_CONFIGURATION_TYPES=Release;Debug -DCMAKE_CROSS_CONFIGS=all
-DCMAKE_DEFAULT_CONFIGS=all -DCMAKE_DEBUG_POSTFIX=d
-DCMAKE_INSTALL_PREFIX=path/to/install

Pick-to: 6.1
Change-Id: I2fa8d3293dd55ebc18937e13fac40d144ca4c1e2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2021-04-20 18:15:33 +08:00
Joerg Bornemann
b226e99c71 Fix DESTDIR handling on Windows for Qt modules != qtbase
On the CI system, we build qtbase with CMAKE_INSTALL_PREFIX set to a
path without a drive letter to support DESTDIR when installing.
Other Qt modules are built without CMAKE_INSTALL_PREFIX set. The
Qt6BuildInternals package provides a default value.

Since commit e6527e2f73 this default
prefix is calculated from the current installation location. This
default prefix however has a drive letter, breaking DESTDIR support.

Broken DESTDIR support in this case means for Android that file(INSTALL)
can properly install but stripping will silently fail.

We now compare the "real path" of the original prefix from qtbase and
the calculated prefix. When they're equal, we use the original
CMAKE_INSTALL_PREFIX.

Fixes: QTBUG-92890
Change-Id: I96fb0655e02c5c695722b7e01a32e209cbdea4cc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 15b26935fca4ab14298abdcc70b3cb15b6cca195)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
2021-04-19 20:42:55 +00:00
Alexandru Croitor
4d838dae5a CMake: Generate better Xcode iOS projects
Add an iOS specific plist file like we do for macOS.

If the user hasn't specified a bundle identifier or a development
team id, do what qmake does and query the Xcode preferences file to
pre-populate those if possible.

This allows running

 cmake -GXcode ./foo

on a Qt example project and building it with xcodebuild on the
command line without having to go through the IDE to set a development
team id or modifying the example project to add a product
bundle identifier.

Note that the change assumes that the development team id has been
previously set / configured via Xcode. If no such id is found, then
the value will not be set and the user will still have to specify it
either in the project file or via the Xcode UI after the project
has been generated.

Amends 3a2fa3fec5

Pick-to: 6.1
Change-Id: Iaab4e57de72c9877fb9035d28f9a879b2c91a33c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-19 20:30:45 +02:00
Alexandru Croitor
b25eb6e0bd CMake: Introduce zlib find script to work around hardcoded iOS SDK
Xcode allows building a project targeting either the device or
simulator sysroot in one single build dir, but for the sysroot
switching to work there should be no linker or compiler flags
referencing absolute paths of a specific sysroot.

During CMake configuration of a project targeting iOS, all found
system libraries will be within one single sysroot, either the device
one or the simulator one, whichever one was passed to
CMAKE_OSX_SYSROOT. CMake will then generate the Xcode project
and pass those absolute paths, which makes sysroot switching within
Xcode not work.

To avoid that, the CMake documentation recommends passing linker and
framework flags of the form '-lfoo' and '-framework bar' instead of
absolute paths. Xcode then takes care of setting the correct framework
search path.

Zlib is one of the libraries found in the iOS sysroot and thus passed
as absolute path.
To avoid that, create a new FindWrapZLIB find script. The target it
creates will pass the absolute path to the library on non Apple
platforms and an -lz linker flag on Apple platforms (macOS and iOS).

To avoid issues with target global promotion when system PNG package
is found, ensure that a found ZLIB::ZLIB target is promoted to global
manually in src/gui/configure.cmake.

Pick-to: 6.1
Change-Id: I8bd8649be4f680a331ad51925f27cb9d13ac5e5f
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
2021-04-19 20:30:45 +02:00