When creating the syncqt custom target we only check if the
WARNINGS_ARE_ERRORS variable is set. But the warnings-are-errors
feature can be disabled using the QT_SKIP_WARNINGS_ARE_ERRORS
target property. Add the genex condition to opt out the
'-warningsAreErrors' argument using the QT_SKIP_WARNINGS_ARE_ERRORS
property.
Change-Id: I8e6f89453500335c2b31e6e69c65b351c79dddc2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When configuring a qtbase developer build, WARNINGS_ARE_ERRORS is
set to ON and -Werror flags are added to the PlatformInternal
targets. But the value of WARNINGS_ARE_ERRORS is not exported.
This means that CMake code can't make decisions based on that variable
when building other repos, and we now have such code with the new
syncqt.cpp in qt_internal_target_sync_headers.
Export the value of WARNINGS_ARE_ERRORS in
QtBuildInternalsExtra.cmake.in.
Fixes: QTBUG-108151
Change-Id: I5de2633fcb1f20fead7d436c201852424e726842
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Process the regular SOURCES and DBus sources the same way in
the qt_internal_extend_target call. Previously the specified
COMPILE_FLAGS had no effect on DBus sources.
[ChangeLog][General] The internal DBus source files that are
generated, now are compiled with the same set of compilation
flags and options as other source files of the Qt module.
Change-Id: I9bdeb8f45c6af1b0cb0235425b0ff7efcb952d59
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Extract function arguments to the corresponding variables and use
variables when parsing arguments. Remove whitespace between if keyword
and parentheses. Adjust size of code lines. Document function-specific
arguments.
Change-Id: I1c77fbf268618a844726683768575aff05894c70
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is a level A SIC, as it breaks
QFile f = "/some/path";
In general, it's not a good idea to have this implicit conversion. A
QFile is not a representation of a path, so the conversion should be
explicit.
I am going to keep the current semantics (implicit conversion) up to and
including Qt 6.8 (LTS). Starting from 6.9, the constructor will be
unconditionally explicit. This is deliberate, and done in order to make
users fix their code while staying in Qt 6, rather than encountering
this issue (and countless many more) if and when they upgrade from Qt 6
to Qt 7. In the meanwhile, users can opt-in to the new semantics by
defining a macro.
[ChangeLog][QtCore][QFile] The QFile constructors that take a path are
going to become unconditionally `explicit` in Qt 6.9. Code like `QFile f
= "/path";` will need to be ported to equivalent one (e.g. `QFile
f{"/path/"}`). This has been done in order to prevent a category of
mistakes when passing strings or paths to functions that actually take a
QFile. Users can opt-in to this change even before Qt 6.9 by defining
the QT_EXPLICIT_QFILE_CONSTRUCTION_FROM_PATH macro before including any
Qt header.
Change-Id: I065a09b9ce5d24c352664df0d48776545f6a0d8e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It might not matter as far as I understand, but having it saved as BOOL
is better if it's a boolean.
Change-Id: If35485425257ca5518f0f8a49ca5353b9ac875a8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
FindWrapSystemMd4c now uses `find_package_handle_standard_args` like
all the other similar modules. This also fixes a case where CMake config
log for finding `md4c` was missing the CMAKE_MESSAGE_CONTEXT,
e.g., `[QtBase]`, which was caused by using `find_package` and let it
log outside the scope of the project, and not `QUIET`ing it.
In addition, the `CONFIG` parameter of the `find_package` was removed to
avoid unexpected issues when 3rd party package managers were used.
Change-Id: Id0bee436e8965452f9089c0e8c8793c3f1b63f02
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Some modules may have header files that do not pass headersclean check
under some conditions. It's nice to have an option in the
qt_internal_add_module function to disable the check for the modules of
this kind. At the moment this flag is useful for the ActiveQt module,
since it syncs and installs header files that don't belong to it.
Amends b89d63515b
Task-number: QTBUG-103196
Change-Id: I21a82d50d50bdac225ed483ab0cc50339c2a4873
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Since QtAutoDetect is called before the project, we still don't have
access to our IOS, WATCHOS, TVOS variables, and we must use
CMAKE_SYSTEM_NAME variable instead.
Pick-to: 6.4
Change-Id: I61afe216baec85b3fcd489957f4b6774134f8078
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In addition, I simplified some of the routines as we don't need the
extra check for them.
Task-number: QTBUG-107903
Pick-to: 6.4
Change-Id: Idaf6ab1338a54bc1a9f242fcc8400ae200174beb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Each module now identifies its actions during the configuration by a
prefix, e.g., `[QtBase]`. In addition,
- I have slightly modified some of the `message()` commands to get
a more coherent output.
- `syncqt.cpp` prints its output as WARNING if any
Change-Id: I3922d75a668d94f402068f4121751b7fcb6522b4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
From CMake 3.7 both flavors of `cmake_parse_arguments` are natively
available in CMake, and loading the
`CMakeParseArguments` module is not needed anymore.
Fixes: QTBUG-107574
Pick-to: 6.4
Change-Id: I7c8a6c5871cdb2f92a4aa43932b6f2ee99e1f57f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
As stated in `QtBuildInternalsConfig.cmake`, `cmake_minimum_required`
versions should be synced with `qtbase/.cmake.conf`, but it wasn't at
the moment.
Change-Id: I8100370778707d46abe973b681fd4aba182a7513
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Avoid using top-level ${target} variable in the function. Align the
module's '_header_check_exceptions' file name, so it should use
_qt_module_interface_name property, but not the qt_module_include_name
proeprty as the prefix.
Amends b89d63515b
Task-number: QTBUG-87480
Change-Id: I1a3ceee1a29f2f4a7cb727310b4fdac63d8144e1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We currently don't have any machinery for qmake or CMake to map
translations declared via TRANSLATIONS += or qt_add_translations
to the Info.plist CFBundleLocalizations key.
This results in macOS and iOS falling back to the development region,
CFBundleDevelopmentRegion, as the only supported localization of the
app, which is in most cases set to 'en'.
Unfortunately this doesn't work well with the behavior of iOS 11+
and macOS 10.13+ where the OS will set the locale of the app to
the best match between the app's supported localizations and the
user's preferred language.
https://developer.apple.com/library/archive/qa/qa1828/
Since we only support a single localization, the development region,
the locale always ends up as 'en_<REGION>', which after QTBUG-104930
is also reflected in the QLocale's uiLanguages(), resulting in the
QTranslator machinery always picking English translation for the app.
As long as we don't explicitly declare CFBundleLocalizations we need
to opt out of the system's behavior of finding the best match between
the app's declared localizations and the user's preferences, which we
can do via the CFBundleAllowMixedLocalizations key.
Fixes: QTBUG-63324
Pick-to: 6.4
Change-Id: If7586d342148cbbb1d2a152cef039aad4448b13c
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
This is consistent with what $(DEVELOPMENT_LANGUAGE) reports, as well as
the Apple Locales Programming Guide which states that "Locale names such
as “English”, “French”, and “Japanese” are deprecated in OS X and are
supported solely for backward compatibility."
Pick-to: 6.4
Change-Id: I99779d678ef9d4ea90249572f2f977e9b4df6c62
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Changed `proviude` to `provide`, and removed an extra space in a `xcrun`
command.
Change-Id: Iccbf6f87b9f4c86b686a6b1d0723458a1387a7ea
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Add Qt configure feature for enabling WebAssembly SIMD usage:
./configure ... -feature-wasm-simd128
Enabling this feature makes Qt add the -msimd128 flag to
the compile options, which enables SIMD instruction usage
for the compiler.
(This should not be confused with the previously added SSE
SIMD support, which uses Emscripten's support for translating
SSE SIMD to WASM SIMD)
Change-Id: I84a36ccef8abf9199c304d68ce371c6b1747b832
Reviewed-by: David Skoland <david.skoland@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The default Windows SDK installed for VC++ 2022 is 10.0.19041, and still
has the issue described here, breaking builds if -Zcpreprocessor is set:
https://developercommunity.visualstudio.com/t/stdc17-generates-warning-compiling-windowsh/1249671
The issue might be fixed in SDK version 2104 (10.0.20348.0), but until
that is the default SDK when installing the compiler, turn that
conformance check off again.
Partially reverts commit 8cb832090a
Change-Id: Ib22f8d196b978274ce31be727826b902e79aaa99
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
/Zc:lambda seems buggy. Although in my experiments it works well
for 99% Qt repos, it seems some tests will trigger the bug and it
also blocks some new commits. So disable it for now, it's not stable
enough.
Now that this check is disabled, the workaround for tst_qstringapisymmetry
is also not needed anymore, so remove the workaround as well.
Partially reverts commit 8cb832090a
Change-Id: Icf0ecbbaa6262522470e5f5dea05705985ab18f1
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
For the full list, please refer to [1].
Needed to change the qstringapisymmetry unit test:
In theory we don't need the array to be static and it did compile
without any problems so far, indeed. However, with this patch applied,
MSVC complains that the lambda function below can't access the array.
I don't understand why, because we use [&] in the lambda and it should
capture all the variables in theory, but in reality it failed to
capture this variable in the end. And making the variable static
solves this issue. Maybe it's a MSVC bug.
Already tested locally. Most Qt repos build without any issues,
only very few repos are not tested, as my local environment
can't build them.
[1] https://docs.microsoft.com/en-us/cpp/build/reference/zc-conformance?view=msvc-170
Change-Id: I658427aa171ee1ae26610d0c68640b2f50789f15
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
On Apple Silicon, Homebrew is installed under `/opt/homebrew` instead of
`/usr/local`, so I made a minor change clarifying this.
Change-Id: Ifccb51325339f80f8ed3c2a4f8acab485686af7e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
These were mostly identical. Use the base clang config
and then specialize for Emscripten in a separate section.
Behavior changes: QT_CFLAGS_OPTIMIZE_SIZE is now -Oz instead
of -Os. Emscripten does not allow -Og, replace that flag
with -O2 -g.
Change-Id: I08163551ad6b84377b99f287983cc1191521055c
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: David Skoland <david.skoland@qt.io>
Currently, emrun will pick the browser to run tests on somewhat
arbitrarily. For predictability and stability, we should use one
browser as a basis, and Chrome seems to be a good fit as wasm features
are generally in good shape on it and it has good support for launching
from command-line.
Change-Id: I1d06a5916ad24ab9df9b0826c0773c652e6d3fcd
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
We aim to allow building Qt for Android on one host, and make it
usable on any host.
Previously when built on a Windows host, we embedded windows style
paths into the android -dependencies.xml files, which caused
androideployqt to fail deployment when building a project on a unix
host.
In Qt 5, the dependencies xml files for Windows Android packages had
unix style paths. Thus switch to always using unix styles paths on
all platforms.
Amends a9d2c5b6d7.
Fixes: QTBUG-107249
Change-Id: I851d3e0b08415b4c7f0d22baf43c10c715879ee7
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Several new headers were extracted from qglobal.h in scope of
QTBUG-99313. This commit makes sure that none of them actually includes
qglobal.h.
As those files are new, it should be safe to introduce this change, as
it shouldn't have any impact on the user code.
This patch also modifies the autogenerated module exports header to
include qglobal.h before the include guard. This is needed to prevent
circular dependencies which result in Q_<MODULE>_EXPORT being
undefined.
Task-number: QTBUG-107046
Change-Id: I8d998792fd8129173d9ec811557e7d7604282813
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Add the -warningsAreErrors command line argument to syncqt.cpp that
causes a fail at build step if any of header files doesn't fit the
syncqt standards. The argument reflects the WARNIGS_ARE_ERRORS CMake
variable state.
Output the syncqt.cpp warnings at configure time.
Fix the faulty positive IncludeChecks failure flag.
Task-number: QTBUG-107088
Change-Id: Id30af4c7b78fd44c1c99c7e9306965d03a0f992d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Otherwise, qmake won't work if the host Qt was built with custom
INSTALL_BINDIR and friends.
Pick-to: 6.4
Task-number: QTBUG-106712
Change-Id: I436103efc21f245cc220f4706adcab369feba836
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The target_qt.conf file contained a wrong HostData value if the
effective data dirs were set to paths of different levels in the host
and target Qt builds. Fix this by computing the relative path from the
mkspec dir's parent to the ext prefix' data dir.
Note that qmake's HostData dir is the root directory of the mkspecs
directory.
Pick-to: 6.4
Task-number: QTBUG-106712
Change-Id: Id8c9de925f5ff51901677b7218621747169a5cec
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Wasm doesn't play well with these baseline tests in general,
so we can disable them for now.
Pick-to: 6.4
Change-Id: I5a66a932449c8934d88b94e419aae5ddcc89ee78
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
syncqt.pl adds an extra dependency on perl when building Qt. Modern C++
provides the convenient cross-platform way to access a filesystem and
to use regular expressions, so we may replace the perl script with C++
application. The syncqt executable is built at configure time and
installed as QtCore tool. It's running at configure time to deliver the
required header files for IDE to build a consistent code model and at
the build time to keep tracking changes in header files and generate
the missing aliases without reconfiguring. 'syncqt' only parses header
files from a CMake build tree, so the resulting Qt installation only
contains interfacing headers that belong to the platform that Qt is
built for. 'sync.profile' files are not used as the 'source of truth'
for sync qt procedure anymore, all the necessary information is taken
from either CMake files at configure time or from the module header
files while parsing them.
syncqt.pl is still in place since it's required as fallback solution
for a smooth transition to the new syncqt implementation for all qt
repositories.
This patchset only enables the C++ based syncqt for 'qtbase'
repository.
From the performance perspective C++ version works faster then perl
script, also the configure time is reduced significally on subsequent
reconfigurations - up x2 times faster when re-configuring repository,
but it also takes time to compile the tool itself the first time.
Numbers for qtbase:
syncqt.pl syncqt.cpp
initial: 0m16,035s 0m20,413s
reconfig: 0m6,819s 0m3,725s
The syncing procedure can be run separately for each module using
<ModuleName>_sync_headers targets. The 'sync_headers' target can be
used to sync all the modules at once.
Task-number: QTBUG-87480
Task-number: QTBUG-103196
Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Avoid the 'file' command shadowing by a variable and use file name when
filtering header files by type.
Amends 8539e641f6
Task-number: QTBUG-103196
Change-Id: If012975efafaf119cffbd89baf84df334bc057ac
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use PARSE_ARGV signature of the cmake_parse_arguments function to avoid
escaping of semicolons when passing arguments to the
qt_internal_add_configure_time_tool and
qt_internal_add_configure_time_executable function.
Amends ac74b60c9c
Task-number: QTBUG-87480
Change-Id: I343abbd75107e56aaccab6e388db8dbda0525af3
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The function does the same as the original one but respects semicolons
in CONTENT argument due to the use of the cmake_parse_arguments variant
with PARSE_ARGV.
Change-Id: I263662dc18e411a735b586995b82791fc6b888ea
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We already have:
a, a timeout as part of QtTest. By default it lets each test function
run for 5 minutes. This timeout can be configured using
QTEST_FUNCTION_TIMEOUT.
b, maxTimeBetweenOutput in the CI. The CI will kill the process if too
much time passes between individual output lines of a test.
c, maxTimeInSeconds in the CI. This does exactly the same as the
androidtestrunner timeout.
The CI timeouts can be centrally tuned per platform and Qt module. This
is preferable over a special timeout just for android.
As other people may be using androidtestrunner for unrelated projects,
don't delete the timeout, but simply disable it from CMake by setting
it to -1.
Task-number: QTBUG-106479
Task-number: QTBUG-101596
Task-number: QTBUG-100242
Change-Id: If4ce00948e204182bb12ac4859d3b0dd193de7ad
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This reflects the true state of exceptions on WASM, which are always
disabled (DISABLE_EXCEPTION_CATCHING is always set with 1).
Change-Id: I7b681846159caf61f291f78a7b4ddf5260dc341f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Make cmake changes that have ctest run the emrun test runner for
all tests that are build for wasm.
Change-Id: I8c07068d79cfd0d745dbcc3d3f025c7c48fe1069
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
_qt_is_test_executable can only be set on a test that is backed by a
real target. QMLTESTs might not backed by an executable target, if
they are missing cpp SOURCES.
Which led to errors like
CMake Error at
cmake/QtTestHelpers.cmake:510
(set_target_properties):
set_target_properties Can not find target to add properties to:
textedit
Call Stack (most recent call first):
tests/auto/qmltest/textedit/CMakeLists.txt:10 (qt_internal_add_test)
Amends 62c681a599
Change-Id: Ie66fd3e94484562061f851c0a034629959d091da
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
QCore::applicationName() is influenced by what values we insert into
the Info.plist file of an application bundle.
We accidentally inserted tokens like ${PRODUCT_NAME} that are meant to
be expanded by xcodebuild, even when using a generator like Ninja.
This caused the applicationName() to report "${PRODUCT_NAME}".
Make sure to only call relevant finalizers for macOS applications
when using a generator other than Xcode.
Amends d5580aa719
Pick-to: 6.4 6.4.0
Fixes: QTBUG-106652
Change-Id: Idbc9c84557a8f17b1302e6969f6eb317e3ef225d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This is needed to later determine what kind of runner should be
selected on WASM for the executable. Tests use the test runner,
whereas other executables use qtLoader.
Change-Id: I75aa361403b72f8e82a288967b8a81b8232d68dc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The _qt_internal_wrap_tool_command function has a limitation
that it is not possible to use it when a command needs to be wrapper
in a generator expression.
Provide a lower level API called
_qt_internal_get_tool_wrapper_script_path
to just get the path to the wrapper script, ensuring that the script
is created if needed.
Deprecate _qt_internal_wrap_tool_command, in favor of replacing it
with the new API.
Pick-to: 6.4
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: Ie4a4a17178bf2061ae01ee2b03b052d84560abf9
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>
Instead of creating the tool wrapper shell script only
during a Qt build in QtBuild.cmake,
ensure it is created any time _qt_internal_wrap_tool_command is
called, regardless if we're building Qt or a user project.
As a transitional period not to break compatibility, we also need
to create the script in QtBuild.cmake, until all usages of
QT_TOOL_COMMAND_WRAPPER_PATH are replaced with function calls.
Currently such usages are present in qtdeclarative.
When considering which bin dirs to add to the script's PATH
environment variable assignment, in addition to the build
internals relative bin dir, also add QT_BUILD_DIR,
QT_ADDITIONAL_PACKAGES_PREFIX_PATH and QT6_INSTALL_PREFIX.
QT_BUILD_DIR is important so we always pick up the just-built
but not installed libraries in a prefix build when running just-built
tools.
QT_ADDITIONAL_PACKAGES_PREFIX_PATH is important when building examples
as ExternalProjects in prefix builds, to ensure that the
not-yet-installed tools and libraries are picked up from the repo
build dir, which is passed via QT_ADDITIONAL_PACKAGES_PREFIX_PATH
to the external projects.
QT6_INSTALL_PREFIX is there in case if the build internals relative
dir is located in a different places than the Qt6 package.
Pick-to: 6.4
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I4d76fbbc275ca961379971054f87991adac36539
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Move it into QtPublicCMakeHelpers.cmake so it is available also when
configuring qtbase and the Qt6Config.cmake file is not yet loaded.
Pick-to: 6.4
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I88127fe0439ae26af1d125eb584244d315574a48
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Move it out of QtConfig.cmake.in into QtPublicCMakeHelpers.cmake
so that the Qt6Config file is less cluttered.
Pick-to: 6.4
Change-Id: I772a0cca35d5c03cd688c3f1de34984484444105
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Before this change, qt_deploy_runtime_dependencies supported Windows and
macOS only. We add a generic deployment method implemented in
cmake-language with file(GET_RUNTIME_DEPENDENCIES). This deployment
method is now enabled for shared builds on Linux.
The file(GRD) command requires that the EXECUTABLE argument points to
the executable in the build directory.
Only libraries in Qt's installation directory are considered for
deployment. This includes Qt's own libraries and also things like
libicu*.so we're shipping with the installer.
Unlike macdeployqt and windeployqt, the generic
qt_deploy_runtime_dependencies does not yet support deploying
translations. We will catch up on this in a later commit.
Change-Id: Iea23abcdba774d4c1885c8d2c243eb3e48fb7fae
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The change b515fa56a3
introduced checking the emsdk version of a qt installation.
However, this checked for QT6_INSTALL_PREFIX where it may not be
defined. This fails when trying to build tests because
when configuring tests, it calls into add_target_helpers which
calls into this logic, and QT6_INSTALL_PREFIX is set after
this is called into, causing the qconfig.h lookup to fail.
To fix this so it works in all conditions,
we need to check if either install prefix or
build_dir is set and use whichever is set.
Pick-to: 6.4
Change-Id: I3cf7e20d3d830f04e5b632fc51d8bf3b2758a717
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt_internal_add_configure_time_executable compiles the executable
at configure time and exposes it to the CMake source tree. This is
useful when need to run a small C++ program at configure time.
Task-number: QTBUG-87480
Change-Id: I031efe797c8afa0721d75b46d4f36f67276bf46e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
<module>-config[-p].h files need to be added to the CMake source tree
Amends 8539e641f6
Task-number: QTBUG-103196
Change-Id: I8baaa672ad869da8a030d890da8bdea5bd8c7794
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This spams the console with "writeStackCookie"/"checkStackCookie"
messages, which makes finding relevant debug output harder.
Pick-to: 6.4
Change-Id: I352b633f02f9ecc1333d1d91f5ffc21a4a937e53
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Avoid adding module header files to a PUBLIC/PRIVATE_HEADER for the
modules. All header files are installed using install(FILES call, but
not as a part of install(TARGET
Amends 8539e641f6
Task-number: QTBUG-103196
Change-Id: Ib95295112c74f74f237e3738d2532f9049d26ce6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If Qt itself is built without the deprecated APIs, so should be the
tools and apps.
This patch makes sure that the specified QT_DISABLE_DEPRECATED_UP_TO
and QT_WARN_DEPRECATED_UP_TO values are correctly used in the internal
tools and apps.
Fixes: QTBUG-105102
Change-Id: I7a51bddbd839c7b71efa0bff8ec959df64c53b82
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use CMake source tree when installing header files instead installing
all header files that syncqt.pl produces. This avoid adding header
files which cannot be used because of platform or feature
incompatibility with Qt version. Since syncqt.pl doesn't respect CMake
build tree when generating master header and CaMeL case header files,
these header files still will be installed regardless platform or
feature limitations. This will not be the case once we switch to
syncqt.cpp, which will install only headers that are relevant to the
selected platform and enabled features.
Task-number: QTBUG-103196
Change-Id: I7d64754648747bee700d96f2fd6228fe7248512e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If Qt itself is built without the deprecated APIs, but the tests are
not, tests will fail to compile and/or link.
This patch makes sure that the specified QT_DISABLE_DEPRECATED_UP_TO
and QT_WARN_DEPRECATED_UP_TO values are correctly used in the tests.
The definitions are propagated to tests, batched tests, manual tests
and benchmarks.
Fixes: QTBUG-104858
Change-Id: Idf15accaf96c47599084426ba625b985f507ca8b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Suppress the pthreads-mem-growth warning for developer builds.
We (the Qt developers) are aware of the issue, so we don't
need the reminder.
Change-Id: Ib924a4dd87b8647d5f1052ab40c0ddf4b9f42108
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The feature does not exist. Do not query for it and assume it's always
off for the purpose of WASM build.
Change-Id: I7e76242c9b3423bfe16872f668c60dae2e74fabe
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
DISABLE_EXCEPTION_CATCHING is added unconditionally on WASM. Add
NO_EXCEPTIONS for all WASM tests since those are never supported.
Change-Id: I2ee10779e7ae0d285494ad650be52dee3099915a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This way it is able to pick up all of the properties assigned to it
before finalization.
Change-Id: I9da635f8620859a669c4e4d589fff56a3ce42ab9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Replace hardcoded Qt6 prefix of module tools target when setting
the name of tools package.
Change-Id: Icb6f38cce766c9d32216a65a8a5ce9552d622b72
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Local file system files are difficult to reach on WASM. Build the test
data in so that it's reachable to WASM tests nevertheless.
Change-Id: I65022db7645248d040434759fb60c3076fd65bd8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Unify the settings for single-threaded and multi-threaded builds;
Qt now always enables heap growth by default.
This means we don't have to reserve a large (1GB) fixed memory
size, but can instead set the smaller (50 MB) initial memory size,
like the single-threaded build does.
Enabling threads + memory growth can potentially cause
a performance regression when accessing heap memory from
JavaScript (https://github.com/WebAssembly/design/issues/1271).
We leave it for the application to decide if this applies,
and if the switch to fixed memory should be made.
Change-Id: I96988b072506456685086e55aca4007a146bd70f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
This will tell developers if they are using the wrong version which may
not build or might cause other issues.
Pick-to: 6.4
Fixes: QTBUG-105922
Change-Id: Ic5c4549d5637182dce380e415f131e33a4da416f
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The new batched test runner is now used for running the tests instead
of the wasm shell, which runs for single test cases.
Change-Id: I7b7e6dd7993ba7937124c5843356b6891301b893
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This implements the build system bits required to build Qt
as as separate wasm modules a.k.a Emscripten side modules.
Enable by configuring with the "-shared" flag.
This is the first step towards shared library support and gets
us as far as being able to load QtCore and instantiate a
QCoreApplication.
Task-number: QTBUG-63925
Change-Id: Ib8f07f80fb5b13c8dbba65c7db735dc557b70d0e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This fixes some threading bugs
Pick-to: 6.4
Change-Id: I1a96dcc54d8338de09b551d52a166d073e85d752
Reviewed-by: Aleksandr Reviakin <aleksandr.reviakin@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Extend the support of pointing at the right test from batch from WASM
to all supported platforms.
Change-Id: I9b6342ed0954f0fdc2f08c76f6b3f24f44f0388a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is useful in some cases where extra parameters have to be set on
the test target.
Change-Id: Ic727fdaf0bc9c2e1c684d1a86352d31c0f974477
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The batch test target name is a useful thing to obtain in various
target-generating scripts.
Change-Id: I9605cf860fe1485e48108eba7e93f9064209d8fb
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The key only applies to macOS bundles. Also, qmake doesn't have it.
Pick-to: 6.4
Task-number: QTBUG-95838
Change-Id: I438f0079cc7b74672dfbe956769138a8bb006669
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Having the build directory encoded in installed files impedes
reproducible builds.
QMAKE_PRL_BUILD_DIR is exclusively used by qmake if 'depend_prl' or
'fast_depend_prl' is active. This is useful for tracking the
interdependencies of libraries within a project but not for Qt's installed
libraries. Even the qmake-based Qt build never used this feature.
Fixes: QTBUG-97386
Change-Id: Icd0801edc1ad92a99fff3a1e92b5f660914813b2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
An approach of test batching (joining multiple tests into a single
binary) has been taken, due to long linking times/binary size on certain
platforms, including WASM. This change adds a new feature
'batch_test_support' in Qt testlib. Based on the value of the feature,
test batching may become enabled with the -batch-tests switch.
Batching works for every target added via qt_internal_add_test. When
first such target is being processed, a new combined target for all of
the future test sources is created under the name of 'test_batch'.
CMake attempts to merge the parameters of each of the tests, and some
basic checks are run for parameter differences that are impossible to
reconcile.
On the C++ level, convenience macros instantiating the tests are
redefined when batch_tests is on. The new, changed behavior triggered
by the changes in the macros registers the tests in a central test
registry, where they are available for execution based solely on their
test name. The test name is interoperable with the names CMake is aware
of, so CTest is able to run the tests one by one in the combined binary.
Task-number: QTBUG-105273
Change-Id: I2b6071d58be16979bd967eab2d405249f5a4e658
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Add source files to the _qt_internal_target_sources property, when
running qt_internal_extend_target on interface libraries instead of
ignoring sources for CMake versions that don't support non-interface
properties. The property is not full-functional, but still allows to
execute internal routines on target sources.
Also add qt_internal_get_target_sources_property function that helps
to destinguish which property stores target sources.
Task-number: QTBUG-103196
Change-Id: I435c558090a24a7988f1a1c49f924dc195e72480
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And also teach CMake to treat it properly instead of hardcoding the
version number.
[ChangeLog][Build System] The configure script now accepts a new
parameter -disable-deprecated-up-to which is used to remove all
deprecated code from API and ABI while building the libraries.
The version number must be specified in a hex format.
For example, it can be used like this:
/path/to/qt/configure -disable-deprecated-up-to 0x060500
to remove all code deprecated in Qt 6.5.0 or earlier releases.
Task-number: QTBUG-101510
Change-Id: I557cf83e29b867fa1052bb097985e144b5eaf34d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The new name describes the behavior in a better way.
[ChangeLog][Build System] The QT_DEPRECATED_WARNINGS_SINCE macro is
renamed to QT_WARN_DEPRECATED_UP_TO. The old name is deprecated, but
is still recognized if it is defined during configuration and the
new name is not defined.
Fixes: QTBUG-104944
Change-Id: I320c033010dfab120db6922598454f95169657f7
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The new name describes the behavior in a better way.
[ChangeLog][Build System] The QT_DISABLE_DEPRECATED_BEFORE macro is
renamed to QT_DISABLE_DEPRECATED_UP_TO. The old name is deprecated, but
is still recognized if it is defined during configuration and the new
name is not defined.
Task-number: QTBUG-104944
Change-Id: Ifc34323e0bbd9e3dc2f86c3e80d4d0940ebccbb8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
It's needed for creating qmake build tests.
CMake / CTest has a limitation of not allowing to create single-config
tests when using a multi-config generator using the add_test(NAME)
signature.
Using add_test(NAME) forcefully creates per-config tests, which means
that it's not possible to just run ctest to execute tests, without
specifying a -C parameter, which we do in the CI.
qmake tests need to use the add_test(NAME) signature
to specify the WORKING_DIRECTORY option.
Because of the above limitation, a work around is to not use the
add_test(NAME) signature, but instead delegate the working directory
assignment to a generated cmake script, which
_qt_internal_create_command_script can already do.
Pick-to: 6.4
Task-number: QTBUG-96058
Change-Id: I6f439165994671724157f0edb7a71e351271e329
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Emscripten's option for enabling asyncify (-sASYNCIFY) is a link-time
option, which means there is no requirement to have a separate asyncify
build, at least for static builds.
Replace the current QT_HAVE_EMSCRIPTEN_ASYNCIFY compile-time option
with a run-time option which checks if the asyncify API is available.
Keep support for configuring with "-device-option QT_EMSCRIPTEN_ASYNCIFY=1"
for backwards compatibility and for the use case where want asyncify
support to be on by default for a given Qt build.
Enable asyncify for the asyncify_exec example.
Pick-to: 6.4
Change-Id: I301fd7e2d3c0367532c886f4e34b23e1093646ad
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The wasm helpers file is not included in QtBuild and is thus not visible
when standalone tests or other repos are being built. This fixes it.
Amends 1f9c1f032c
Pick-to: 6.4
Fixes: QTBUG-105615
Change-Id: I6c9229e1f259fa5043d7d11b8ee0293e26077f3e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This ensures that tests can be executed on the simulator or device, by
doing the necessary steps like setting a bundle identifier, Info.plist
file, launch screen, etc.
This is done by calling _qt_internal_finalize_executable in the
implementation of all internal test adding functions.
The finalizers are limited only to iOS for now, as an incremental
step, and to ensure we don't accidentally break tests on other
platforms.
At least WebAssembly uses its own finalizers which would likely cause
duplicate calls if the _qt_internal_finalize_executable was
unconditional.
Pick-to: 6.4
Fixes: QTBUG-104754
Change-Id: I729d56385dd206b22c975fc2ce4e2c683e6e4e2c
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Variables starting with 'arg_' usually are the result of the
cmake_parse_arguments call. It's better to not use them for the regular
variables for readability.
Change-Id: I4054c63d3e48b2a27d8a632cd8908a59302afa47
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
HEADER_MODULE argument is passed to qt_generate_module_pri_file from
the qt_internal_add_module function, but the property means that the
module is an interface library. So it makes sense to replace this
argument with the reading of the target TYPE.
Change-Id: I1d8cd2ff732f526975cde6bdd4783fee44c8bd98
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Developers can add to Emscripten's EXPORT_RUNTIME_METHODS
by defining their own using:
QT_WASM_EXTRA_EXPORTED_METHODS
Which will add on to Qt's default exported runtime methods
of UTF16ToString,stringToUTF16
for cmake:
set_target_properties(<target> PROPERTIES QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap")
or
set(QT_WASM_EXTRA_EXPORTED_METHODS "ccall,cwrap")
for qmake:
QT_WASM_EXTRA_EXPORTED_METHODS = ccall,cwrap
Done-with: Mikolaj Boc
Fixes: QTBUG-104882
Pick-to: 6.4
Change-Id: I9678bdb7b077aaa8527057212ea4e161c0be0b60
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When loading a Qt CMake project in an IDE like Visual Studio, many
Qt-internal targets are visible, right next to the user's targets. This
is inconvenient and confusing.
Use CMake's FOLDER concept, and put Qt-internal targets into a dedicated
FOLDER.
For that we introduce the new global property QT_TARGETS_FOLDER that,
analoguous to AUTOGEN_TARGETS_FOLDER, is the folder name for Qt-internal
targets. By default, it's not set, nor is folder support enabled.
Change qt_standard_project_setup() to
- enable folder support
- initialize QT_TARGETS_FOLDER if unset
- initialize AUTOGEN_TARGETS_FOLDER to the same value if unset
Set the FOLDER property of qtbase's internal targets for user projects
to the value of QT_TARGETS_FOLDER.
Task-number: QTBUG-99808
Change-Id: I880ac7731f88faa83a384dcdec98b1b88ac6cc2e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The current qt_internal_extend_target interface expects that the caller
will pass the HEADER_MODULE argument on each call. This is not correct,
since the argument doesn't affect the target internals, but only help to
decide how to modify the target according to its type. The target type
meanwhile can be always read from target properties. So this solution is
more consistent.
Change-Id: Ie84a2226ceb71cb5272670e5d43bdfc7a101360a
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
The qlalr outputs need to be added to the consuming target.
Change-Id: I9600729103298cf7e0a712d5f3dc49c5f4c729f5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
...if the double-conversion CMake package cannot be loaded.
The find_path call must specify the header exactly as it is included.
The select_library_configurations call always failed, because the
command expects the presence of DOUBLE_CONVERSIONS_LIBRARY_DEBUG,
DOUBLE_CONVERSIONS_LIBRARY_RELEASE, or both.
Upstream double-conversion's MSVC build system does not specify a naming
scheme for the debug build, and there are no debug/release binaries to
download that suggest a naming scheme. Therefore we assume the usual
'd' suffix for the debug library like we do everywhere else.
Lastly, we need to set DOUBLE_CONVERSION_INCLUDE_DIRS.
Fixes: QTBUG-105501
Pick-to: 6.2 6.3 6.4
Change-Id: I71ff5238f353541b8bf5ac6792b86134deba20d1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add the support of pre-cooked content for the LD version script. The
content can be generated without using the perl script at configure
or build time.
Change-Id: I1316e114a1d5550b2fdcf3482a51f336fb311a29
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Add headersclean_check that allows to run all module-specific
'_headersclean_check' targets in single command. Also add
dependency on input header files for the headers clean custom
commands.
Also adjust the '_headersclean_check' target names to match
the naming of module targets - the 'Qt' prefix is removed.
Change-Id: I17c3442c3c51ce99cd9b38c85d606e9ababbb013
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Previously configuration would not error out if you configured Qt
with -DCMAKE_CONFIGURATION_TYPES=RelWithDebInfo;Debug -GNinja
instead you would get an error like
CMake Error at cmake/QtBaseConfigureTests.cmake:51 (message):
Failed to find compiled architecture detection executable at
qtbase/build/config.tests/arch/RelWithDebInfo/architecture_test.exe
Note that Qt code tries to find the arch test in a RelWithDebInfo
directory but due to using single-config Ninja,
CMAKE_CONFIGURATION_TYPES is ignored, and the executable is placed
in a non-config specific folder.
Error out early in such a case, and mention that for multi-config
builds, the Ninja Multi-Config generator should be used.
Pick-to: 6.4
Change-Id: I0192185123be563671cbe154f968a03b7458e327
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
All supported CMake versions provide this file, and we did not modify
it.
Pick-to: 6.4
Change-Id: I4b21a99159ba8315491dc64ab737b7e5a28a6966
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Matches qt_generate_module_pri_file and allows using genexes in the
content of the file.
Change-Id: I5ee7a973d3e27a721e31315d3ebe2c88ffa1db42
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The same way qt_generate_module_pri_file does it.
Change-Id: I42047ce7d23e8a289535041ccace8b0f0140ea12
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Allows adding additional properties to the target after the initial
call to qt_internal_add_plugin.
Change-Id: I7998c906e53699ec41b44b51aabbe480ae698b21
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
qt_copy_framework_headers now can accept all the headers in one call.
This is useful for upcoming changes when it will accept generator
expressions as the input instead of actual files.
Change-Id: I110b6d9e6de976b2a7581902e051e38571716c5f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We forwarded the compiler path to the EP but not the flags that might
have been set via the CXX environment variable.
Make sure to also forward the flags.
Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I0fbf9b595f7885014b1f09d158db52e56a3d5243
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
When building qtsvg examples as external projects on Windows
with Ninja Multi-Config in a prefix build on the CI, the build would
fail with an error message like:
ninja: error:
'C:/Users/qt/work/qt/qtsvg/lib/Qt6SvgWidgets.lib', needed by
'RelWithDebInfo/svgviewer.exe', missing and no known rule to make it
This can be reproduced locally on Windows if one calls
'ninja svgviewer' instead of just 'ninja'. I wasn't able to reproduce
it on macOS, although I have seen some peculiarities in the
dependencies there as well.
External project examples depend on the ${repo_name}_src custom
target to ensure all Qt modules are built, so one would expect that
dependency to be sufficient.
While trying to figure out what's going wrong, I noticed that running
'ninja -t query qtsvg_src:Debug' showed dependencies on Release
libraries, which should not happen. The :Release target looked fine
though.
I'm still not quite sure why the Release libraries are not built
on the first ninja run, despite the example having a proper dependency
on qtsvg:Release.
Running 'ninja svgviewer' a few more times ends up succeeding at one
point, because the SvgWidgets Release library does get built in
parallel with the failing example, and the next rebuild would
succeed.
While trying to fix the :Debug target to have proper dependencies, I
noticed that we add dependencies to the ${repo_name}_src custom target
via the DEPENDS option of add_custom_target(). That is incorrect,
that option should only be used for file level dependencies.
For target dependencies, add_dependencies should be used.
Doing that fixed both the :Debug dependencies as well as the Windows
issue, which is good enough for me.
Amends 08f46bb400
Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I1888681e2e9362d3237acbdacc83222d6a60b48e
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The simulator build of Qt for iOS is currently x86_64 only, instead
of universal builds with an arm64 slice as well, since we don't
support xcframeworks. This means we can't rely on Xcode's default
simulator arch settings, which on an Apple Silicon Mac will be
arm64.
Instead we override the simulator arch, like we do for qmake.
Pick-to: 6.4 6.3 6.2
Change-Id: I8b52389db1b83f4f9679c724bcde53b44dbc76f1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When using qt-cmake-standalone-test, we didn't tell CMake to use the
same C++ language standard that Qt used when it was configured.
We did tell CMake to do that when configuring tests with
qt-internal-configure-tests via the qt_build_tests macro.
To ensure the proper standard is set, we also need to
find_package(Qt6Core), because the std flag is derived from the
QT_FEATURE_cxxyz flag which is set by Core.
Change-Id: Ia41f2a24983ddab0107a6446743f7b054df8c033
Pick-to: 6.2 6.3 6.4
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Previously if qtbase was built with feature A set to ON, then building
qtsvg, then rebuilding qtbase with feature A set to OFF, trying to
build qtsvg would fail with an error message at configure time saying
that the feature value has changed.
This check was added quite early in the Qt CMake port, presumably to
catch accidental reconfigures that might cause long rebuilds.
This has dubious benefit though. We constantly had people telling us
they get the error without knowing what to do. The usual advice was to
remove CMakeCache.txt and reconfigure.
Instead of forcing people to suffer this dance, relax the constraint
by issuing a warning instead of an error, and make it more clear why
a rebuild might happen (a changed feature value might change
the generated module C++ header file which in turn might be included
by various project sources).
Amends 20633d97ab
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-95834
Change-Id: I992bd61024958869f3b995471b4c7ff75e3a33a0
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
All references to these variables have been removed from Qt
repositories.
Change-Id: Icca4668ec183ff543d04097600f8a8869066f8cc
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Add an option to limit the number of tests for building and testing
Android multi-ABI configurations in CI. Currently only Core tests
supposed to run.
Change-Id: Ibb8a41d60d108259ef2675ec54bde2482f87c8b2
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Warn projects not to use it because PUBLIC_LIBRARIES don't make
sense for executable targets and it also led to some issues in the
internal functions where some of them did not expect to receive
PUBLIC_LIBRARIES.
To ensure builds don't needlessly break, treat PUBLIC_LIBRARIES values
as regular LIBRARIES. In the future we might add an error instead.
Using PUBLIC_LIBRARIES in qt_internal_add_app, etc, accidentally
worked because the option name and the values following it were
parsed as values of the "previous" option, like SOURCES or
INCLUDE_DIRECTORIES or LIBRARIES, and when those got
passed through to qt_internal_extend_target, things magically worked.
We have a lot of projects using PUBLIC_LIBRARIES, mostly due to the
way qmake pro files were written and how pro2cmake converted them.
We'll have to clean up each repo.
Change-Id: I69e09d34afdf98f0d47c08d324643fc986f8131c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Needed to get rid of warnings like
CMake Warning at cmake/QtFindPackageHelpers.cmake:406
(message): Could not find target Qt6::BundledLibYaml to query
its package name. Defaulting to package name Qt6BundledLibYaml.
Consider re-arranging the project structure to ensure
the target exists by this point.
which were introduced with the integration
of dffcc2370e in qtbase.
This happened because we never set and exported the package names
for 3rd party bundled libs.
So export the package name as well as "is 3rd party lib" value.
Amends 6235f7fa62
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I25fc1ffef766198974025e0097bced1cca4dd28d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Add PlatformCommonInternal to the list of packages
compared in qt_internal_is_lib_part_of_qt6_package
It gets rid of the following warnings when configuring
standalone tests
CMake Warning at cmake/QtFindPackageHelpers.cmake:406 (message):
Could not find target Qt6::PlatformCommonInternal to query its
package name. Defaulting to package name Qt6PlatformCommonInternal.
Consider re-arranging the project structure to ensure the target
exists by this point.
CMake Warning at cmake/QtFindPackageHelpers.cmake:374 (message):
Could not determine package version of target
PlatformCommonInternal. Defaulting to project version 6.5.0.
Amends 606124c5cc
Amends dd1030a450
Amends dffcc2370e
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I65c23c20b3c1b70dbfd54edd4f5b83c6781f5e6f
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously we called _qt_internal_override_example_install_dir_to_dot
in Qt6CoreConfigExtras.cmake as part of a
find_package(Qt6 COMPONENTS Core) call, and we assumed that the
Extras file would always be included in each example project.
But our package dependencies handling code skips calling
find_package(Qt6Core) if Qt6Core_FOUND is already set to TRUE,
which will definitely happen due to root-scope find_package
calls when configuring other repos.
That means we wouldn't override INSTALL_EXAMPLEDIR to "."
and the install destination would end up being something like
${CMAKE_INSTALL_PREFIX}/example_relative_path/example_relative_path
aka a double nested path.
Make sure we call the
_qt_internal_override_example_install_dir_to_dot function
in Qt6ConfigConfig.cmake in addition to Qt6CoreConfig.cmake.
That way, even if Qt6Core is skipped during dependency resolution,
it's still handled by the Qt6 package itself.
Because the function is defined in the Core package, guard the call
with an if(COMMAND) and only call the function if it wasn't previously
called within the current or ancestor scopes.
Amends ac4a913f33
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-102879
Change-Id: Id47e3ce06faec6d156ae1473942dae0f9b90cb46
Reviewed-by: Christophe Giboudeaux <christophe@krop.fr>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
To support per-target iOS launch screens we need a way to specify
custom Info.plist entries without using cache variables, which we were
forced to use due to the implicit configure_file done for
MACOSX_BUNDLE_INFO_PLIST.
We now introduce an extra configure_file call done in a finalizer,
before we hand off the Info.plist file to MACOSX_BUNDLE_INFO_PLIST.
This extra configure_file call allows us to insert / substitute
additional Info.plist entries that CMake does not allow setting.
If a custom Info.plist file is provided, the finalizer will simply
skip the logic for creating a new one.
Amends e5b3436255
Pick-to: 6.4
Fixes: QTBUG-101064
Change-Id: I65496da146c9430a949a8163817021d54da28386
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Otherwise we don't create a Qt6FooPlugins.cmake file in shared Qt
builds.
Adjust comment.
Amends f68e2c92cc
Related to 7d6f1ee5a7
Change-Id: I9c66d81197a4867039d5c53daf1b7edf0391c701
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
In Qt6, the installed tools can be in one of two different locations,
depending on whether it is considered a helper or not. This means that
when migrating from Qt5 to Qt6, the pkg-config files no longer reliably
described where to find tools such as moc, uic, and rcc, which
third-party projects need to know about in their build systems.
Add this information in, to match qmake -query and Qt6CoreConfigExtras.cmake
Task-number: QTBUG-105051
Pick-to: 6.2 6.3 6.4
Change-Id: I6692a76e0491a1c5e28982aa5fbe8b8aec8dec56
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Regardless of the current log level.
Somewhat similar to dd5c860a7b
Amends e2a0ddbb69
Pick-to: 6.2 6.3 6.4
Change-Id: Ib7bc87f07e195125c858dcece2df6e82303dd01c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The __qt_internal_include_plugin_packages function includes
PluginConfig.cmake files which in turn might look for dependencies
with find_dependency. The dependencies that were found not have their
_FOUND variables set in the calling scope, which could cause multiple
lookups of the same dependency packages.
Change the function to be macro, so that all relevant _FOUND variables
are set and no unnecessary package lookups are done.
As a result, no need to set the QT_ALL_PLUGINS_FOUND_BY_FIND_PACKAGE
variable using set(PARENT_SCOPE)
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Iba0fc83d9e58651f095e7b70d1ed19f064c4e577
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This matches what we do in Dependencies.cmake files, except this time
for COMPONENTS passed to the Qt6 package.
For example if a project does
find_package(Qt6 COMPONENTS Widgets Core)
we'd end up looking for Core twice. Once as a dependency of Widgets
and once as a standalone request of the project.
Make sure to skip the second lookup if it was already found.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I61db7fbb99818b4b70a0bfe3e167b6f14732292e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Removing the variable would cause nested find_dependency calls of
FooQmlPluginDependencies.cmake files to look for the Qml package
again and again.
If we got to the point of including QmlPlugins.cmake, we already know
that the Qml package was found.
Set it to TRUE after every inclusion to avoid repeated Qml package
loading.
The second inclusion pass will ensure to set the found variable to
FALSE in case if some dependency is actually missing.
Amends aad4158959
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I562a1c2ea0abac61453a743ab2e7d2f228de7ff0
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously if a target depended on CorePrivate, we would write a
_qt_internal_find_qt_dependencies(... Qt6CorePrivate) call into a
FooDependencies.cmake file.
That find_qt_deps call would remove the 'Private' suffix and would run
find_dependency with NAMES set to both the altered and non-altered
names.
This would find the relevant package but it would set the wrong
_FOUND variable name, e.g it would set Qt6CorePrivate_FOUND instead
of Qt6Core_FOUND.
This in turn could cause multiple lookups of the Qt6Core package
during dependency handling because the correct _FOUND var would not be
set.
Instead of always looking for the Qt6CorePrivate package, make sure
we look for an appropriately named package for all Privates modules,
because we have the necessary info to determine the correct name.
Note that INTERNAL modules will still be looked up via a Private
suffixed package name because that's how the package name is chosen
for them.
Remove the code that accounted for Private modules in
qt_internal_remove_qt_dependency_duplicates because it's not needed
anymore.
Warn when a package name can't be queried from a target's property
because the target might not exist yet.
Add a TODO comment for the code that searches with two NAMES.
We can't remove it right now, because it might break user projects
that use stale Dependencies.cmake files.
The dbus subdirectory is added before the tools subdirectory
to ensure that the new package name extraction does not error out, due
to trying to access a target that does not yet exist.
Amends 425ff34aa1
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Ib34ae5ed92f68b4265518c2b8802daeb1a3a04d6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously we did not create Qt6:: namespaced aliases.
This is needed as a workaround preparation for getting the package name
of a module target from one of it's properties.
Before it would fail in qtinterfaceframework because
ifvehiclefunctions-simulation-server uses PUBLIC_LIBRARIES
in its qt_internal_add_app call, and because _add_app does not handle
such an option, some weirdness in qtbase's _add_app -> _add_executable
-> _extend_executable -> _register_target_dependencies ended up trying
to register PlatformAppInternal as package dependency.
That issue will be handled in separate changes.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Ifd03528c95b08cb6837a6aaa26cbf97c0cbabbb4
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
When loading Qt packages, don't look for the Qt6 dependency if it was
already found in the given subdirectory scope.
This reduces the amount of find_dependency(Qt6) calls.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I737c4433daf30eed51a058b45cd539dff7657ca4
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Instead of trying to compute and validate the QT_HOST_PATH and
QT_HOST_PATH_CMAKE_DIR variables in the generated toolchain file,
do it in the Qt6 package.
This provides better error messages when a project is configured
without using the Qt generated toolchain file.
Because it's not done in the toolchain anymore, remove the various
host variables from __qt_toolchain_used_variables.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I1ca239ff83b8f783897e171fee352fc43e8ad7a8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Instead of checking if QT_HOST_PATH is set during user project
configuration to find out if Qt6HostInfo should be looked up,
record if QT_HOST_PATH was provided during Qt configuration
into Qt6Dependencies.cmake and look up the package in a user
project based on that information.
This improves handling of the case where cmake is directly used
to configure a Qt project (instead of qt-cmake), which means no
QT_HOST_PATH might be set by the user, and then cmake would error out
saying that e.g. Qt6CoreTools is not found, instead of saying that
Qt6HostInfo is not found.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I0377d5440e4b5b295af73cfd4b5188f61d48e440
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Also replace the duplicate call in QtSetup using the
new function.
To do that, we have to actually the call it in QtBuild
after QtPublicDependencyHelpers.cmake is available.
That call is needed so that Qt6_HOST_INFO_foo variables
are available in qt_generate_qmake_and_qtpaths_wrapper_for_target.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Ic5776c214bee6bedcea714b213b0e5a42c1bae06
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It's perfectly possible to create static plugins in an otherwise shared
Qt build, but the logic to import these plugins into applications was
assuming a fully static Qt build. We now handle this more granularly.
Change-Id: Iacfa72f04c7918613b50ca87cf123e7f4c0841d5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The CMake build system files are properly generated, but the qmake parts
were missing.
Change-Id: Icbcce3143db976c536c802ea2314bc3f2595da51
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
It's perfectly possible to create static plugins in an otherwise shared
Qt build, but the logic to import these plugins into applications was
assuming a fully static Qt build. We now handle this more granularly.
This works for in-source tools and tests as well, which don't go through
the same CMake machinery for plugins as user projects do. The only case
that does not currently work is in-source examples, as they don't share
any of the plugin machinery with neither Qt internal tools/tests or user
project, but that's a bigger architectural issue that goes beyond this
change.
Change-Id: Ie00a97b02ac38ec4affadc447a3bfd0ec7d9c69a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This patch improves the QT_INLINE_SINCE(maj, min) macro to take
deprecation version into account.
If the specified (maj, min) version is less than or equal to the
version defined by QT_DISABLE_DEPRECATED_BEFORE, the macro will expand
to "inline", and the out-of-line fallback will be removed from the
library.
This is achieved by introducing the helper
QT_IF_DEPRECATED_SINCE(major, minor, whenTrue, whenFalse) macro.
Fixes: QTBUG-104131
Pick-to: 6.4
Change-Id: I285029dad7b71126072b024a3be6d7b11341996d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Fix existing warnings by casting to the appropriate type.
Change-Id: Ic44d2a71e1a2e508199dbb46bea7a19e183ec42c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
In cross-compilation, the CMAKE_FIND_ROOT_PATH will have path to the
host Qt and examples build will pick up wrong Qt6Config.cmake unless
the build dir path is prepended.
Pick-to: 6.4 6.3 6.2
Fixes: QTBUG-104270
Change-Id: I7fc7499369a2e5446e1c5257155f81c72716fef7
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
And take the opportunity to remove the "m" in the qmake feature name and
.prf file.
Pick-to: 6.4
Change-Id: I36b24183fbd041179f2ffffd170224ab75cdd968
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Clang has the option, but spells it differently.
Fixes: QTBUG-105002
Pick-to: 6.4
Change-Id: I36b24183fbd041179f2ffffd170217e82ff6d14d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To enable CET for MSVC, only passing "/CETCOMPAT" to
the linker should be sufficient.
Enabling generation of EH Continuation (EHCONT) metadata
is additional protection and should not be necessary.
It also requires all the dependencies to be re-compiled
with EHCONT enabled, otherwise the linker will refuse
to link the obj files. However, this is rather hard
to achieve if your application depends on many 3rd-party
libraries, so to let people enable CET more freely,
we don't enable EHCONT guard by default.
Pick-to: 6.4
Change-Id: Iba08a5ec56c474d291991fb751a0de764719bd85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
When a Qt component or dependency is not found, we will now show a
message that the user can reconfigure the project with
-DQT_DEBUG_FIND_PACKAGE=ON.
If the option is enabled, various variables that find_package uses to
find packages (like CMAKE_PREFIX_PATH, CMAKE_FIND_ROOT_PATH) will be
recorded before each find_package / find_dependency call that is
executed in any of the Qt package files.
If any find_package call fails (a package has its _FOUND variable set
to 0), the values of all those recorded variables will be shown.
This is useful to troubleshoot issues, especially when
cross-compiling, without having to manually modify the various
Config files.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I3654960597911bd704fbe3c419bcae347ab739a9
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Depending on CMake version suggest usage of either
--debug-find-pkg or CMAKE_FIND_DEBUG_MODE to help troubleshoot
why dependent packages are not found.
To achieve that, append the hint message to the _NOT_FOUND_MESSAGE.
To ensure it works for qt dependencies, and not only tool and 3rd
party dependencies, _qt_internal_find_qt_dependencies
is modified to set variable names infixed by the target name, so the
name is consistent with the other dependency lookup functions.
The check and message are also added when a Qt6 component is not
found.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I4ef23d1c53ac8e04eb72c260d6860c1eeec8d7a3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
So far we always recommended that developers set CMAKE_PREFIX_PATH to
point to the location of the Qt installation so that Qt packages are
found by CMake.
In Qt5 one could also set the Qt5_DIR variable to $qt/lib/cmake/Qt5
to allow the following signature to work:
find_package(Qt5 COMPONENTS Core)
This was not sufficient in Qt6 because the CoreTools dependency would
not be found.
Fix this by also looking into the parent folder of
CMAKE_CURRENT_LIST_DIR as well as _qt_cmake_dir, like we already do
for regular non-Tools packages in _qt_internal_find_dependencies.
Note that setting Qt6_DIR is not sufficient for cross-compilation if
the qt.toolchain.cmake file is not used.
Aside from platform specific options that would have to be passed
manually to CMake (like -DCMAKE_SYSTEM_NAME=iOS for iOS) and
passing a QT_HOST_PATH value, the code would also need to be
adapted to do the necessary CMAKE_FIND_ROOT_PATH manipulations
to ensure that dependent packages are found.
Pick-to: 6.4
Task-number: QTBUG-97615
Change-Id: I10c419632d43bb929e184bab3b9d3d27a35ea87a
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
When a package's tools dependency is not found (e.g. Core's CoreTools)
set the _NOT_FOUND_MESSAGE variable the same way that find_dependency
does.
We can't use find_dependency directly because that returns immediately
without allowing us to reset the prefix paths vars.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I81e9817de8f30214fafbefe3d98ef7bc8848e715
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
If find_package(Qt6 REQUIRED COMPONENTS Core) is called, don't
propagate the REQUIRED option to all the dependencies of Core,
regardless if it's a 3rd party library, tool or another Qt package
dependency.
Propagating REQUIRED causes the find_dependency -> find_package call
to exit the calling file immediately when the package is not found,
not giving an opportunity for find_dependency to set the
_NOT_FOUND_MESSAGE variable.
Instead force all find_dependency / find_package calls
to be optional, set the calling _FOUND variable to FALSE if the
dependency is not found, also set the _NOT_FOUND_MESSAGE variable.
Then the find_package call that loaded FooModuleConfig.cmake file
will show that message as the reason for the package not being
found.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Idcf0b6ed6f6bb38dc082110bbd817b05e287c052
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
If a project calls find_package(Qt6 COMPONENTS Gui Network) and Gui is
not found, there's no reason to look for Network, because the
COMPONENTS option implies that it is a required component. Failing to
find a component sets Qt6_FOUND to false, so we can break early.
If a project calls find_package(Qt6 OPTIONAL_COMPONENTS Gui Network)
then Network will still be looked for if Gui is not found.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I5c5edd27729635e6b7ade059656b49320364ad13
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Use _qt_internal_find_third_party_dependencies instead.
We rely on the inner find_dependency call to set the
Qt6_NOT_FOUND_MESSAGE message when a dependency is not found.
This implies removing the custom FATAL_ERROR handling
and relying on the parent find_package to display the
Qt6_NOT_FOUND_MESSAGE message.
We also clear Qt6_FIND_COMPONENTS if a dependency is not found.
No need to look for Qt packages if the Qt6 dependency was not met.
This reduces the amount of recursive error messages.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I5c611aaededfa63eb507ec5385b37a2fb6fcc698
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Aside from moving the code to reduce duplication, the only changes in
the code are the replacement of @target@ to ${target}, using IN LISTS
with variable names to avoid macro expansion issues and replacing
the if(var) conditions with double variable evaluation
+ NOT STREQUAL "".
The function implementations are now in the same order as they
are used in the Dependencies.cmake files.
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: Iaae926414fd2a7cc09c2f5716376caaa0aade74b
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
It was accidentally left when changes were made from patchset 1
to patchset 2 in 825cb50c27
Amends 825cb50c27
Pick-to: 6.4
Task-number: QTBUG-104998
Change-Id: I04dd50cfb93655f0c224bb226695e7771e9bc5d1
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Make the target purpose more understandable from its name.
Change-Id: I4f4a56fd3ef338b728d4a81edc2df32cada97f6c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The only place the function was used was to generate the title case of
a target, so the issue wasn't spotted until now.
Pick-to: 6.2 6.3 6.4
Change-Id: Iee66ecea569e7411c6b5a5e5312cde910a48fa01
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
- 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
