Commit Graph

1745 Commits

Author SHA1 Message Date
Joerg Bornemann
8b5cce6911 CMake: Fix prefix propagation for relocated Qt installations
Consider qtbase built with CMAKE_STAGING_PREFIX=/foo on Windows.
If /foo was moved to /bar, non-qtbase repositories did get a staging
prefix with drive letter assigned.  This is undesirable when DESTDIR is
used on installation.

Change the implementation of qt_internal_new_prefix to remove the drive
letter from the "new prefix" if the "old prefix" did not have a drive
letter.

Change-Id: I6fb17e690b264920b0dd4204e3b3c30794c7e76e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-13 12:52:00 +02:00
Alexandru Croitor
3d1464fc15 CMake: Process extra dependencies for plugin targets as well
We started recording extra dependencies for the QtNetwork TLS plugin,
but we never actually processed them to write out the necessary
find_package calls.
This broke static builds of qtopcua, because the OpenSSL::SSL target was
no longer created in the root scope, but only in some child ones like
src/opcua, whereas the target was referenced in generator expressions
in a different sibling scope src/declarative_opcua, leading to errors like

 CMake Error at lib/cmake/Qt6/QtPrlHelpers.cmake:116
  (file): Error evaluating generator expression:
    $<TARGET_LINKER_FILE:OpenSSL::SSL>
  No target "OpenSSL::SSL"
 Call Stack (most recent call first):
  lib/cmake/Qt6/QtModuleHelpers.cmake:837 (qt_generate_prl_file)
  lib/cmake/Qt6/QtScopeFinalizerHelpers.cmake:21:EVAL:1
     (qt_finalize_module)
  src/declarative_opcua/CMakeLists.txt:DEFERRED

Make sure to process the extra deps for plugins as well.

Amends d754e43721
Amends 3c23317552

Pick-to: 6.4
Task-number: QTBUG-96283
Change-Id: I11876e0844198b3a794bc06b6691ee694fd3b1c2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-11 22:23:09 +02:00
Alexandru Croitor
0d1c16861a CMake: Clarify qt_record_extra_third_party_dependency docs
Pick-to: 6.4
Change-Id: I458a5b488741c639650c8b3b6668c82c80b5e93f
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-11 22:23:09 +02:00
Joerg Bornemann
8cc58fbbc7 CMake: Propagate qtbase's original staging prefix to other Qt repos
If qtbase was configured with CMAKE_STAGING_PREFIX set to a path without
drive letter on Windows, we must ensure that this exact staging prefix
is propagated to non-qtbase repos.

We already had code that does this for CMAKE_INSTALL_PREFIX.  But since
9a74d94ff5 we build our cross-built
packages with CMAKE_STAGING_PREFIX instead of CMAKE_INSTALL_PREFIX.

Move said code into a function and use it for CMAKE_STAGING_PREFIX too.

This fixes Android non-qtbase release libraries not being stripped in
our Windows Android packages.

This amends commit 037fd545c4.

Fixes: QTBUG-104827
Pick-to: 6.2 6.3 6.4
Change-Id: I909f7f39bd0ef7b559619b69f756c042d6c528b0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-11 19:43:41 +02:00
Alexandru Croitor
bea66711d8 CMake: Don't create duplicate plugin targets in shared builds
when building Qt repositories.

When building for example qtquick3d, the Qt6QmlPlugins.cmake
file should not load the qtquick3d specific plugin config files
because the targets will be created as part of the build and cause
duplicate errors.

We already did it for static builds, but now we also do it for shared
builds.

Amends 7d6f1ee5a7
Amends 98e8180e56

Pick-to: 6.4
Task-number: QTBUG-94066
Change-Id: I66ca71dfa6485eded94c1ecb5eb3b23daf908b39
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-08 15:07:38 +02:00
Tor Arne Vestbø
e27a0d5a0f Disable bitcode for iOS
It's deprecated as of Xcode 14, and generates a warning message if a
project explicitly enables bitcode. The App Store no longer accepts
bitcode submissions from Xcode 14.

Pick-to: 6.2 6.3 6.4 5.15
Change-Id: Ib1f9d5114ca4d8b1845ecc7a9de0473ee015db33
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-07 17:02:37 +02:00
Morten Sørvig
5b23f08b81 wasm: use simpler syntax for EXPORTED_RUNTIME_METHODS
Recents emsdk versions support specifying the method list without
using brackets. Switch to this syntax since that avoids any quoting issues.

Pick-to: 6.4
Change-Id: Ib7bf8ec3f0d2ef67e8222a23e7af9b368ee99a00
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
2022-07-06 17:56:58 +02:00
Joerg Bornemann
df764df3ea Fix potentially wrong version in Windows resources of Qt plugins
qt_internal_add_plugin calls qt_set_target_info_properties with the
TARGET_VERSION argument and passes arg_VERSION.  However, the function
qt_internal_add_plugin does not have a VERSION argument.

If arg_VERSION is set before calling qt_internal_add_plugin, that value
will be used, and that could be wrong for the plugin.

Remove the TARGET_VERSION argument from the
qt_set_target_info_properties call.

Pick-to: 6.4
Change-Id: I0ae9e0e6636d74fdc20e6ab9ca525c5a9126000c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-06 12:20:40 +02:00
Yuhang Zhao
6af63c8256 CMake: Update description of the Intel CET feature
Use a more detailed description instead.

Also adds the missing part of the GCC parameter.

Amends commit qtbase/42287255d38bf493b5731396b99bc9cd7b1baba4

References:
https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Instrumentation-Options.html#Instrumentation-Options

Change-Id: I94a22ac7dfa80644e92fe01021f7868dfa02dd69
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-06 00:31:47 +08:00
Joerg Bornemann
fc3e0885a6 CMake: Fix missing include directories from qmake support files
The include paths in QMAKE_INCDIR_FOO entries in qt_lib_XXX.pri files
are filtered to not contain implicit include directories.

We must enclose the regular expression with ^...$ to avoid catching too
many paths like any subdirectory of /usr/include.

Fixes: QTBUG-104736
Change-Id: I2d40e6ec6d3f3421d591fed90b4dd9ebbbeb59f4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-07-05 13:55:19 +02:00
Alexandru Croitor
7d6f1ee5a7 CMake: Create and include plugin packages in shared builds
Previously QtModulePlugins.cmake files were only created and
included in static library Qt builds.

Having the targets available in shared library builds would be
useful for custom project deployment purposes. One could query
the location of the plugins or use various generator expressions
referencing their location.

Ensure we always generate and include the QtModulePlugins.cmake files
regardless of the build type.

Allow opting out of including the files by setting
QT_SKIP_AUTO_PLUGIN_INCLUSION to ON, just like we allow for Qml
plugins with QT_SKIP_AUTO_QML_PLUGIN_INCLUSION.

Pick-to: 6.4
Fixes: QTBUG-94066
Change-Id: I69a5dc17762a8e43265578fc33b82b5c4b7a1f5c
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-05 13:04:09 +02:00
Alexandru Croitor
ff4be4cf30 CMake: Move plugin package inclusion logic into a common function
Don't duplicate the logic of plugin package inclusion for each Qt
module. Instead move it into QtPublicPluginHelpers.cmake.

Pick-to: 6.4
Task-number: QTBUG-94066
Change-Id: I5e1f5176a0e754ed56a792c97865752529462617
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-05 13:04:09 +02:00
Alexandru Croitor
eb8da02d05 CMake: Improve 'Generating Plugins' message
Use message(STATUS) for the 'Generating Plugins' message.

This way it will go to stdout instead of stderr, which follows the
convention we have for most of our other messages.

Also list only the modules that actually have plugins, rather than all
known modules.

Pick-to: 6.2 6.3 6.4
Change-Id: I1ea0ed71418ede54790cabd32e03e82fc69f2858
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-05 13:04:09 +02:00
Alexandru Croitor
9ea2f7f4b1 CMake: Fix qml plugin prl files not to have hardcoded paths
The previous fix 754512a64d
did not handle qml plugins, which meant that they would still have
hardcoded paths and see warnings like the one below when generating
the prl files

 CMake Warning (dev) at
 cmake/QtFinishPrlFile.cmake:103 (message):
  Could not determine relative path for library
  qml/QtQml/WorkerScript/libworkerscriptplugin_debug.a
  when generating prl file contents.  An absolute path will be
  embedded, which will cause issues if the Qt installation is
  relocated.

Handle qml plugins as well.

Amends 754512a64d
Amends f4e9981259

Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104708
Task-number: QTBUG-104396
Change-Id: Icfb1069d1cb0a39a35004b20e58ee6e386d14f3b
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-02 00:11:12 +02:00
Alexandru Croitor
d59628881e CMake: Fix confusing FPHSA zstd version warning message
Previously if zstd was not found, one would see such a warning message

 Could NOT find WrapZSTD: Found unsuitable version "", but required is
 at least "1.3" (found ZSTD_LIBRARY-NOTFOUND)

This is because PC_ZSTD_VERSION was a defined variable with an empty
value, which makes FPHSA believe that a version was extracted from
somewhere.

Avoid passing that value directly.

Now the warning message is

 Could NOT find WrapZSTD (missing: ZSTD_LIBRARIES ZSTD_INCLUDE_DIRS)
 (Required is at least version "1.3")

Pick-to: 6.2 6.3 6.4
Change-Id: I88760d94db0d869d328085996298f4aaa88bc6c2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-02 00:11:12 +02:00
Alexandru Croitor
a310319a04 CMake: Rewrite double-conversion find module
Rename FindWrapDoubleConversion.cmake into
FindWrapSystemDoubleConversion.cmake.
Merge contents of Finddouble-conversion.cmake into the one above.
This allows users to provide their own Finddouble-conversion.cmake
file (Conan can do it).
Don't mark the system package as required, because we have a bundled
one too.
Add link to upstream.
Make sure to show either Config file or library path when one is
found.

Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104541
Change-Id: I9ea2330697c6fc280328849ca11522291c4073d8
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-02 00:11:12 +02:00
Alexandru Croitor
af56a6f0cb CMake: Don't force CONFIG mode when looking for system PCRE2
This allows picking up 3rd party Find modules. One use case is
Conan-generated Find modules.

Also add TODO in case we ever need to handle finding the upstream
target name rather than the Hunter chosen one.

Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104542
Change-Id: I243987c657f74e8127076666d9734b2b657bc0ee
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-02 00:11:12 +02:00
Alexandru Croitor
bfd9e195a3 CMake: Fix lookup of system PCRE2 version
The version option needs to be specified before the COMPONENTS
option, otherwise it is treated as another component.

This causes failures when a Conan provided FindPCRE2.cmake script is
picked up, which actually does validation of component names based
on the component information stored in the conanfile.py recipe.

Move the version value to be before COMPONENTS.

Amends 1007aac63a

Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-104542
Change-Id: I92c70f266a07c4aabdadcecda1ba7e107a033604
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-07-02 00:11:12 +02:00
Alexandru Croitor
dd1030a450 CMake: Record used package version for each target dependency
When recording which package version to look for in
QtFooModuleDependencies.cmake and other files like it,
instead of using PROJECT_VERSION, use the version of the
package that contains the dependency.

For example if we're hypothetically building the qtdeclarative repo
from the 6.4 branch, against an installed 6.2 qtbase, then
the Qt6QmlModuleDependencies.cmake file will have a
find_package(Qt6Core 6.2) call because qtdeclarative's
find_package(Qt6Core) call found a 6.2 Core when it was configured.

This allows switching the versioning scheme of specific Qt modules
that might not want to follow the general Qt versioning scheme.

The first candidate would be QtWebEngine which might want to
follow the Chromium versioning scheme, something like
Qt 6.94.0 where 94 is the Chromium major version.

Implementation notes.
We now record the package version of a target in a property
called _qt_package_version. We do it for qt modules, plugins,
3rd party libraries, tools and the Platform target.

When we try to look up which version to write into the
QtFooModuleDependencies.cmake file (or the equivalent Plugins and
Tools file), we try to find the version
from a few sources: the property mentioned above, then the
Qt6{target}_VERSION variable, and finally PROJECT_VERSION.
In the latter case, we issue a warning because technically that should
never have to happen, and it's a bug or an unforeseen case if it does.

A few more places also need adjustments:
 - package versions to look for when configuring standalone
   tests and generating standalone tests Config files
 - handling of tools packages
 - The main Qt6 package lookup in each Dependencies.cmake files

Note that there are some requirements and consequences in case a
module wants to use a different versioning scheme like 6.94.0.

Requirements.
 - The root CMakeLists.txt file needs to call find_package with a
   version different from the usual PROJECT_VERSION. Ideally it
   should look for a few different Qt versions which are known to be
   compatible, for example the last stable and LTS versions, or just
   the lowest supported Qt version, e.g. 6.2.6 or whenever this change
   would land in the 6.2 branch.
 - If the repository has multiple modules, some of which need to
   follow the Qt versioning scheme and some not,
   project(VERSION x.y.z) calls need to be carefully placed in
   subdirectory scopes with appropriate version numbers, so that
   qt_internal_add_module / _tool / _plugin pick up the correct
   version.

Consequences.
 - The .so / .dylib names will contain the new version, e.g. .so.6.94
 - Linux ELF symbols will contain the new versions
 - syncqt private headers will now exist under a
   include/QtFoo/6.94.0/QtFoo/private folder
 - pri and prl files will also contain the new version numbers
 - pkg-config .pc files contain the new version numbers
 - It won't be possible to write
   find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code.
   One would have to write find_package(Qt6WebEngineWidgets 6.94)
   otherwise CMake will try to look for Qt6Config 6.94 which won't
   exist.
 - Similarly, a
   find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call
   would always find any kind of WebEngine package that is higher than
   6.4, which might be 6.94, 6.95, etc.
 - In the future, if we fix Qt6Config to pass EXACT to its
   subcomponent find_package calls,
   a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets)
   would fail to find WebEngineWidgets, because its 6.94.0 version
   will not be equal to 6.5.0. Currently we don't pass through EXACT,
   so it's not an issue.

Augments 5ffc744b79

Task-number: QTBUG-103500
Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-01 10:50:57 +02:00
Alexandru Croitor
74d8321771 CMake: Don't show the incompatible version warning when not needed
If a find_package(Qt6Foo) call has the QUIET option passed, don't
display the incompatible version warning.

Also if the find_package call has the EXACT option passed, and the
searched for version does not match the package version exactly,
there's no point in showing the warning because find_package
will reject the package anyway, even if we set
PACKAGE_VERSION_COMPATIBLE to TRUE

Pick-to: 6.2 6.3 6.4
Change-Id: I78ef95cf4a045034fc50853465f3ba1db84bba63
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-07-01 10:50:55 +02:00
Thiago Macieira
db342f42a4 CMake: update the x86 intrinsic checks
Merge all the existing checks into a single one, which is a simple pass
or fail, since all our supported compilers support all the intrinsics up
to Cannon Lake. The two I've recently added (AVX512VBMI2 and VAES)
aren't yet supported everywhere, so they stay.

For some reason, all intrinsics seem to be disabled on Android. It looks
like some support was missing during the CMake port and this was never
again looked at. I'm leaving it be.

As for WASM, discussion with maintainers is that the WASM emulation of
x86 intrinsics is too hit-and-miss. No one is testing the performance,
particularly the person writing such code (me). They also have some
non-obvious selection of what is supported natively and what is
merely emulated. Using the actual WASM intrinsics is preferred, but
someone else's job.

Change-Id: Ib42b3adc93bf4d43bd55fffd16c10d66208e8384
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2022-06-28 03:28:42 +00:00
Thiago Macieira
500c116ced CMake: disable the attempt to force SIMD on iOS simulator builds
This will stop working with the next commit, which merges all basic x86
SIMD intrinsics into one configure test. As a result, linking almost
anything graphical on iOS (which is almost everything) causes the linker
to fail with undefined references to SIMD-optimized versions that didn't
get compiled.

Change-Id: Ib42b3adc93bf4d43bd55fffd16c288f4104a6ccc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
2022-06-27 20:28:41 -07:00
Kai Köhne
267db4eab4 Doc: Skip 'qt5/' part in 3rd party documentation
Pick-to: 6.4
Fixes: QTBUG-104463
Change-Id: I7596118e147c9b5b12b49c4cf2692626697f309e
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
2022-06-23 01:30:23 +02:00
Thiago Macieira
c83a87eca7 CMake: fix build with FreeBSD 13.1
I don't know if they've just added the libs and therefore the GSSAPI
content wasn't enabled before, but libgssapi_krb5.so does not have the
symbols we need.

ld: error: undefined symbol: gss_acquire_cred
>>> referenced by qauthenticator.cpp:1803 (/usr/home/tjmaciei/src/qt/qt6/qtbase/src/network/kernel/qauthenticator.cpp:1803)
>>>               src/network/CMakeFiles/Network.dir/kernel/qauthenticator.cpp.o:(qGssapiTestGetCredentials(QStringView))

ld: error: undefined symbol: gss_release_name
>>> referenced by qauthenticator.cpp:1808 (/usr/home/tjmaciei/src/qt/qt6/qtbase/src/network/kernel/qauthenticator.cpp:1808)
>>>               src/network/CMakeFiles/Network.dir/kernel/qauthenticator.cpp.o:(qGssapiTestGetCredentials(QStringView))
[...]

Pick-to: 6.2 6.3 6.4
Change-Id: I6d3880c7d99d4fc494c8fffd16fabf70bbd272f5
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-06-22 12:42:11 -07:00
Alexandru Croitor
754512a64d CMake: Fix prl files not to contain hard-coded library paths
Make sure to convert absolute paths generated using the
$<TARGET_LINKER_FILE> generator expressions into relative paths.

Because prl files are generated for both modules and plugins, we need
to pass both a list of qt module locations and qt plugin locations
to QtFinishPrl.cmake, and then try to make the absolute path relative
to each passed directory.

A warning assertion is shown if we no relative path could be made,
which will cause an absolute path to be embedded. This should not
happen though.

Amends f4e9981259

Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104396
Change-Id: Id68395c0dbb20aad5c510d77835cc931b9396556
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-06-22 20:18:39 +02:00
Lorn Potter
1e2d67152f wasm: Optimize use of opengles
- USE_WEBGL2 is depreciated, Emscripten now uses MAX_WEBGL_VERSION
- Optimize and remove use of emulated ES2 and ES3, which means
only use WebGL friendly subset.
Users can add USE_ES3=1 and USE_ES2=1 to the final linker arguments
for those respective versions in order to enable using
glDrawArrays and glDrawElements with unbound buffers.
See https://emscripten.org/docs/porting/multimedia_and_graphics/OpenGL-support.html

Pick-to: 6.4
Change-Id: I11ae359966964b3e7aa6e61ccc714c2bfbf61f96
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
2022-06-22 13:59:25 +10:00
Marc Mutz
06f21a3870 headerclean: remove dead code
The variable was misspelt, so we obviously don't need these
exceptions.

Pick-to: 6.4 6.3 6.2
Change-Id: I691c9315bcde3aad72410ce01ae6dc6a013ee6fd
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2022-06-22 03:09:24 +02:00
Marc Mutz
97f643faee Long live QT_INLINE_SINCE!
We have now had several requests for inlining previously-exported
member functions, but no standard mechanism to effect it.

As QT_REMOVED_SINCE has shown, there is great value in having such a
standard mechanism, so here is one.

With this change, to inline a previously exported (member) function,
simply

- mark the declaration with QT_<MODULE>_INLINE_SINCE

- move the definition into the header file (outside the class),

  - wrap it in QT_<MODULE>_INLINE_IMPL_SINCE

- #include the header into the module's removed_api.cpp

Just including the header into removed_api.cpp is enough, so you may
want to add a comment:

    #include "header.h" // uses QT_<MODULE>_INLINE_SINCE

The effect is as follows:

- A TU in a _different_ library will see an inline declaration,
  followed by the definition, and so it will see a normal inline
  function.

- A TU in the same library will, however, see a non-inline
  declaration, to avoid the ODR violation that at least GCC/ld are
  able to detect.

  - When QT_<MODULE>_BUILD_REMOVED_API is in effect, the TU will also
    see the definition, which is the same setup as before the change,
    except in a different TU, and therefore export the member.

  - When, OTOH, QT_<MODULE>_BUILD_REMOVED_API is _not_ in effect, the
    TU will see no declaration, assuming (correctly), that the
    definition will be supplied by a different TU.

This is, of course, an ODR violation, but not worse than what we do
elsewhere, as the definitions differ only between library and user.

The function is inline only for the users of the library, not the
library itself, which will still see the function as non-inline. If
inlining is critical within the library, too, the existing function
should call a new inline function, and calls in the same library should
be changed to call the new inline function instead.

Use the new mechanism to inline the QLocale ctor we intended to inline
for 6.3, but couldn't, because we hadn't found the magic incantation,
yet. Thiago found it a few weeks later, and this is what this patch is
based on.

Fixes: QTBUG-100452
Pick-to: 6.4
Change-Id: Ia0030cddc64b6b92edfed860170d5204aa74b953
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
2022-06-22 01:09:24 +00:00
Yuhang Zhao
11e6e9bccd CMake: Mark chosen C++ standard as required for building Qt
Change-Id: I7d3187e74251059c7536f3e34d8c87f54c673146
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-06-19 14:45:07 +08:00
Alexey Edelev
4d7ba44e4d Add missing argument to list(APPEND in __qt_internal_get_tool_imported_location
Amends f9e48854af

Pick-to: 6.4
Change-Id: Iea525c70cca9873c0f3d96967af6cd95d57cac9b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-06-17 18:02:24 +02:00
Alexandru Croitor
b3e3b12489 CMake: Warn when using CMake 3.21.1
Changing a C++ source file can trigger rebuilds of a lot of other
source files that might include AUTOGEN'ed headers or sources.

See https://gitlab.kitware.com/cmake/cmake/-/issues/22531 for some
details. Fixed in CMake 3.21.2.
There are still files that are rebuilt even in 3.21.2, but it's less,
and it returns to the status quo of how it was in 3.21.0 or earlier
versions.

Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-104352
Change-Id: Ie1c991d52df48442d4134e4ed22a8137a3c993c8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-06-16 19:29:35 +02:00
Dimitrios Apostolou
fe0e87c9a6 Add ASAN build for qtbase
The test run is wrapped with a special TESTRUNNER script that ignores
failing tests (there are several tests failing when built with ASAN) and
also ignores LSAN errors (memory leaks - but still visible in the
output).

The test run only fails if a test reports ASAN errors or if it
crashes (or times out, which is like a crash caused by qtestlib's
watchdog timer).

Fixes: QTQAINFRA-5025
Change-Id: I861756ab49388ac4a52409d3a780684244e469b1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-06-15 23:58:16 +02:00
Marc Mutz
ecbe56825a modulecppexports.h.in: re-indent nested preprocessor directives
Amends 0d9f4e7526.

Task-number: QTBUG-100452
Pick-to: 6.4 6.3 6.2
Change-Id: Iaa6626853a4241f750a6929fc9f604a149c874eb
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2022-06-14 03:30:48 +02:00
Kai Köhne
04cc705947 CMake: Fix typos
Found by codespell

Pick-to: 6.4
Change-Id: I4907e423b6b345acf82f2d7e0ed62479719d694e
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-06-13 15:37:36 +02:00
Thiago Macieira
88f5955cb7 CMake: up the minimum C version to C11
We're in 2022. A 11-year-old C standard probably suffices, especially
since we require C++17 anyway.

Pick-to: 6.4
Change-Id: Ibcde9b9795ad42ac9978fffd16f3555327097ded
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-06-11 10:58:43 +00:00
Alexandru Croitor
b3d0325a8d CMake: Ensure top-level builds are affected by our chosen log level
This will hide the configuration summary and cmake feature summary and
found packages output upon reconfiguration.

Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-104128
Change-Id: I42270b99e45076052ec176df4652661cae10ac0c
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2022-06-10 21:10:34 +02:00
Alexandru Croitor
dd5c860a7b CMake: Show configuration summary on first configuration
or when feature changes are detected, even when the log-level is set
to NOTICE (which is the default for non-developer-builds).

We want to show the summary during the first configuration so we don't
force users to look into the config.summary file.

We want not to show the summary upon reconfigurations, to keep regular
reconfigurations as quiet as possibe, so it's easy to notice any new
warnings.

Amends e2a0ddbb69
Amends 384dfceb53

Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104127
Change-Id: I506f33b4bae9da8957e04bb69c206bf00e3f7b0e
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
2022-06-10 21:10:34 +02:00
Joerg Bornemann
f318c0e2d6 CMake: Find system harfbuzz even if pkg-config is disabled
FindWrapSystemHarfbuzz.cmake relied on pkg-config to find system
harfbuzz.  This patch makes it find system harfbuzz even if pkg-config
is not available or disabled.

Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-103894
Change-Id: I2a8fc64c738c7604f47de89f387002e40a9fa5e0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-06-10 14:25:45 +02:00
Joerg Bornemann
71a0b893fb CMake: Fix check for system harfbuzz if pkg-config is unavailable
We need to check whether pkg_check_modules returns success before
setting up target name etc.

Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-103894
Change-Id: I12702639683723d976e93be95443099b88885869
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-06-10 14:25:41 +02:00
Joerg Bornemann
4cef4f1c1b Make configure -no-pkg-config actually work
Turning off pkg-config with the configure flag -no-pkg-config did not
work.  There are different defaults for FEATURE_pkg_config on different
platforms (e.g. Linux: ON, Windows: OFF).  The existing code that
calculated the initial FEATURE_pkg_config value assumed that the default
is OFF and never turned the feature off.

Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104123
Change-Id: I33b9687c55c60d4ec9224324951a8838741ee976
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-06-10 14:11:09 +02:00
Allan Sandfeld Jensen
dc3b2ac81d C++23/c++2b support
Change-Id: I33b2a48312ae94e3d5ebb4097e50c4953e14d533
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-06-08 19:43:34 +02:00
Lorn Potter
acfcd1e61f wasm: Replace depreciated --embind compiler argument
As of Emscripten 3.1.3, the --embind compiler argment has been
depreciated for -lembind

Change-Id: Iac5bc21602f27fda7c1ea6814a1c9525b9a5afab
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
2022-06-02 19:11:58 +10:00
Morten Sørvig
86103f3af5 wasm: don't enable specialHTMLTargets by default
Adding specialHTMLTargets to EXPORTED_RUNTIME_METHODS carries the
obligation to actually use it as well; failing to do so makes Emscripten
stop with a reference error on startup.

However, we can't guarantee that Qt will use it in all cases. The
current usage depends on QGuiApplication being used. Application code
could be using QCoreApplication, or no application object at all.

Detect if specialHTMLTargets is present instead, and then enable the code
paths which uses it if that's the case. This means that apps which want
to use e.g. multiple browser windows can opt into support by making sure
EXPORTED_RUNTIME_METHODS contains specialHTMLTargets.

Change-Id: I81105aa01946602fcf593f170e305d7dc9bad3be
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
2022-06-01 13:52:47 +02:00
Ville Voutilainen
5431b40ee8 Avoid some new clang 14 warnings on Android NDK 24 build
Task-number: QTBUG-99663
Change-Id: I1aa408ba468342e2fac2323ae91ff650b871c563
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
2022-05-27 17:28:37 +03:00
David Skoland
1a0eb4fa01 Adjust installing and running wasm-testrunner
Added a small helper function that also installs the script to
prefix builds. Additionally, leveraging the cmake option
CROSSCOMPILING_EMULATOR for the testrunner fits neatly in the rest
of our cmake code.

Change-Id: I75288e97c81b250ac3997f2e7a22bc7bd82b7b69
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-05-27 14:50:17 +02:00
Lorn Potter
e3757df526 wasm: update emscripten to 3.1.10
Qt 6.4 will require Emscripten 3.1.10

Change-Id: I34d6288489b6674f6fd75134dd1855ae931c79c2
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: David Skoland <david.skoland@qt.io>
2022-05-27 17:46:29 +10:00
Alexandru Croitor
55eb94cdbd CMake: Use the PRODUCT_NAME for the iOS display name like qmake
This ensures that the Xcode 'Display name' input under
${target} -> General -> Identity -> Display name is not empty.

Because adding ${PRODUCT_NAME} directly in the Info.plist.in template
will cause CMake to evaluate it as variable expansion, work around the
issue by putting the dollar sign into a separate cache variable that
after evaluation will result in ${PRODUCT_NAME} being in the file
verbatim, so that Xcode evaluate it at build time.

Amends 4d838dae5a

Pick-to: 6.2 6.3
Task-number: QTBUG-95838
Change-Id: I2d1090cc8e84b32442f7daca2d4ce5e3ad413c68
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-05-20 13:06:06 +02:00
Alexandru Croitor
c0188b2dbd CMake: Fix issue with linking against static library on iOS
Currently our iOS CMake toolchain file sets the global
XCODE_EMIT_EFFECTIVE_PLATFORM_NAME property to OFF, to work
around a CMake issue regarding usage of object libraries in
conjunction with Xcode. The error was

 The OBJECT library type may not be used for IMPORTED libraries under
  Xcode with multiple architectures $(CURRENT_ARCH)

While this got rid of the error, it introduced a regression where
linking an executable against a static library in the same project
failed due to the library not being placed in a directory where Xcode
expects it to be.

 clang: error: no such file or directory:
  '~/build-untitled4-Qt_6_0_2_for_iOS/Debug/libuntitled4.a'

The actual library is created in Debug-iphoneos/libuntitled4.a
Note the -iphoneos suffix, which is related to the
EFFECTIVE_PLATFORM_NAME.

This could be further worked around by either explicitly setting the
library ARCHIVE_OUTPUT_DIRECTORY property in the project, or flipping
the value of the XCODE_EMIT_EFFECTIVE_PLATFORM_NAME to ON at the
end of the project. Both workarounds are not project-friendly.

In the mean time CMake got a fix for the original error
at https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5771
which got released with CMake 3.20.0.

That was unfortunately not sufficient to remove our initial
workaround, because removing it would trigger a different
error at generation time

CMake Error:
  Error evaluating generator expression:
    $<TARGET_OBJECTS:Qt6::Quick_resources_1>
  The evaluation of the TARGET_OBJECTS generator expression is only
  suitable for consumption by CMake (limited under Xcode with multiple
architectures). It is not suitable for writing out elsewhere.

Fortunately, another fix landed in CMake 3.21.0 to address that
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6161

Because static builds (iOS) require CMake 3.21, with both of these
fixes we can now remove our workaround.
Even projects that set ARCHIVE_OUTPUT_DIRECTORY or flip
XCODE_EMIT_EFFECTIVE_PLATFORM_NAME to ON still continue to work
fine.

This also fixes installation of libraries, which also took into
account the effective platform name and thus caused a mismatch between
the expected output dir and the real one.

This reverts 1e1805ed36

Pick-to: 6.2 6.3
Fixes: QTBUG-93268
Fixes: QTBUG-95381
Task-number: QTBUG-87198
Change-Id: Ifcaf0f89e4328ae9859c596882ce32401fa491c3
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-05-20 13:06:03 +02:00
Alexandru Croitor
a3917126e8 CMake: Automatically use Xcode generator in qt-cmake + iOS
When calling qt-cmake on the command line, we don't usually force
usage of a particular CMake generator and defer to the user's choice
or CMake's default for the host OS.

In the case of iOS, the generator that makes the most sense to use is
Xcode. One could also use Ninja / Unix Makefiles if the project
is only building static libraries, but for shared libraries and
executables the project likely needs the code signing
provided by xcodebuild.

When targeting iOS, use a different qt-cmake file template.

The iOS-specific shell script will set the CMAKE_GENERATOR environment
variable to 'Xcode'.
If no -G or -D CMAKE_GENERATOR is provided on the command line then
the project will use the Xcode generator. Otherwise the generator
given on the command line takes precedence.

The CMAKE_GENERATOR environment variable from the parent process is
completely ignored.

The logic is only done for iOS, to reduce the likeliness
of breaking the qt-cmake script for other platforms.

Note that Qt Creator does not use qt-cmake, but rather calls cmake
directly with additional options like the toolchain file,
architecture, sysroot, etc.

[ChangeLog][iOS][CMake] qt-cmake now defaults to using the Xcode
generator when targeting iOS projects.

Pick-to: 6.2 6.3
Fixes: QTBUG-100834
Change-Id: I39b3dce47cc9ee2f98678631e4bd035c59c65294
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-05-20 13:06:00 +02:00
Li Xinwei
9539c8a7f8 CMake: set correct COMPILE_PDB_NAME for static libraries
Output names of static libraries might be different from target names.
For example, the library name of Qt6::DeviceDiscoverySupportPrivate is
"Qt6DeviceDiscoverySupport.lib", and the library name of
Qt6::QTlsBackendCertOnlyPlugin is "qcertonlybackend.lib".
This commit make pdb files names consistent with the library names.

And make sure we have set correct OUTPUT_NAME property before calling
qt_set_common_target_properties()/qt_internal_set_compile_pdb_names().

Change-Id: Idb3cacd7a46a4f298fd584b927b5d726956faea8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-05-20 17:41:20 +08:00