This provides better stack traces and easier debugging in CI VMs.
Put the MSVC check for disabling stripping into the same place so
there's one location to decide whether stripping should happen.
Amends 60d804c567
Pick-to: 6.6
Fixes: QTBUG-118070
Change-Id: I4684036c8a5a137d14eea58954b34fe1ceb7f804
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
TL;DR: This creates two changes:
1. Makes the plugin inclusion status more visible for builders for both Qt
itself and applications.
2. Allows a simple patch-point for distros to change the default
(perhaps not ideal, but good enough).
3. Does not changes the current behavior.
As discussed both in the mailing list and privately with
Alexandru Croitor and Joerg Bornemann this makes a lot os sense for Qt
on static builds and when trying to find where the plugins are so they
can be easily packaged up in order to distribute a build with all the
dependencies on it.
But at the same time it makes no sense for distributions building the
libraries in dynamic mode as it forces unnecesary build time
dependencies for for both Qt and applications like QML modules or even
PostgreSQL! [0].
[0] <https://sources.debian.org/src/martchus-qtutilities/6.10.0-1/cmake/modules/QtConfig.cmake/?hl=35#L35>
Other approaches have been considered like not shipping specific CMake
files, but this depends on the packager finding the right ones at the
right time, and does not allows end users to change the behavior if they
happen to need it.
Change-Id: Id32fbc0cf0f289edd4426fb703cf1195288aacb4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
As mentioned in comments, file(COPY causes rebuilding of the file every
time the project is re-configured, so, we replace it with configure_file
to avoid that.
Amend 1dcc14f2d0
Task-number: QTBUG-118191
Change-Id: I893b36fa26168f460f3ab1320a3194561c66e5df
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
On iOS, we can use system color variables to adjust the background color
of the LaunchScreen based on user's system preference. In addition, we
can remove the app name labels, since new Xcodes don't add it anymore.
Fixes: QTBUG-118191
Change-Id: I95fef6216f1373c749ea31ff4ed085435e8998f1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The currently provisioned OpenSSL for Android, i.e.,
`prebuilt-openssl-3.0.7-for-android-ndk-r25b.zip` has a different
structure compared to what Vcpkg installed directory has. This patch
makes sure that we are considering the Vcpkg structure as well.
CMAKE_ANDROID_ARCH_ABI should be translated to Vcpkg's triplet target
name, and we add a `-dynamic` suffix to them because we are building
android artifacts with a custom triplets with similar names.
Change-Id: Id48a8ad351a64ab18001f729d948fbf1b7e47b29
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Qt ModuleConfig.cmake files set variables like <package>_INCLUDE_DIRS,
<package>_DEFINITIONS, etc., which can be used by user projects to
acquire the module related information. These variables also accumulate
information from Qt Module dependencies. Since we do not separate the
Private and regular modules in dependency list, the resulting variables
contain values from both. This change puts the information from Private
dependencies to the variables of Private module. The exception is
PRIVATE_INCLUDE_DIRS which will contain include directories from Private
dependencies for non-Private module too.
Fixes: QTBUG-118462
Change-Id: I51e6d63651ed1913005064c90f77eba219cf60ea
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
A bug in Xcode 15 adds duplicate flags to the linker. In addition, the
`-warn_duplicate_libraries` is now enabled by default which may result
in several 'duplicate libraries warning', and build failure if
`-Wl,-fatal_warnings` is passed. By adding the newly introduced
flag, `-no_warn_duplicate_libraries`, to the linker we can suppress the
warnings, and possible fatal error caused by this bug.
Change-Id: I65e06ea039a6e98b02ed1f9112c622ecc6a142b5
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The 'dependencies.yaml' file contains entries that aligned with the
repository naming but not the Qt projects naming. When parsing
it to collect the dependencies for the standalone repo we should
cut the 'tqtc-' repo prefix to avoid malformed names in
QT_REPO_DEPENDENCIES variable.
Pick-to: 6.5 6.6
Change-Id: If80e61394f245f09b620a9210246053d4e475f86
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This reverts commit 885d87488a.
Reason for revert: Issue was caused by a faulty `.pc` file which was reported to upstream, in addition, the patch might not be effective in certain cases as tested by the reporter. See the bug report for further information.
Change-Id: I2b75a79f47b77a660bd23cd41df40df9ea4baef2
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Change the heuristic only to use the stored compiler if we
are building qt itself, like with qt-cmake-private
/ qt-configure-module. qt-cmake is also used by end-users,
where the heuristic to change the compiler default base on
paths is surprising, and can go wrong.
Fixes: QTBUG-108323
Pick-to: 6.6
Change-Id: I0274e470f214a84711013d77068551f9097f4685
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
pkgconf is an alternative implementation of pkg-config, and it is mostly
compatible with pkg-config, but in the case of HarfBuzz, it adds the
`/usr/local/include` to `INTERFACE_INCLUDE_DIRECTORIES` when reports the
include path, and if the path doesn't exist, the configuration fails.
In the case of HarfBuzz, we do some extra work to make sure that we can
always find the library, so, with a bit of modification, we can skip the
faulty pkgconf intervention and create the correct imported target.
Fixes: QTBUG-117905
Change-Id: Id628e4434633534b0d7bfad9e819a8c05da4944d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We look for all Qt components when attempt configuring standalone
tests. If some 3rdparty dependencies are missing in user environtment
the configuring proccess will fail even if the dependency is not used
by the standalone tests. Avoid requiring the Qt components, so users
will see only warnings about the missing comonents or dependencies.
Fixes: QTBUG-117709
Pick-to: 6.6 6.5
Change-Id: Iecce40449cdf116f1a7c279ebb161f0f5c7f6a9f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
'.' in the regexp must be escaped.
e.g. "/qt/toolchain.cmake" matches "/qt.toolchain.cmake$"
Pick-to: 6.5 6.6
Change-Id: Ib6b66349e1619908a33b4a11d79f7ba19d0e8fdc
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Configure time executables don't adopt new cmake flags if they were
changed. Cache all flags that were used when building configure time
executables and consider changes when decide rebuilding them.
Pick-to: 6.6 6.5
Change-Id: Ifba77833f362c790120f0ab1f808a855327bc49f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Build system adds this flag to any module that it uses when built as a
shared library and not WASM.
VxWorks is specific in regards to type of applications:
- static application, which do not use any dynamic libraries
- dynamic application, which uses shared libraries, and as such needs
to link against libdl.a
The latter is the only source of symbols related to dynamic loading and
thread local storage. This is an architectural decision, as application
is required to embed loading tools in itself (as opposed to Unix/Linux,
which contains dynamic loader which provides these symbols separately).
libdl.a is standard static library on VxWorks, compiled without PIC, and
as such can't be linked into shared library.
This results in compilation errors when building dynamic libraries which
use `thread_local`-related symbols, since these symbols will be
fulfilled at runtime (contained in executable which requires shared lib)
and are not available during linking.
Don't add `-Wl,--no-undefined` flag on VxWorks for Qt shared lib builds.
Task-number: QTBUG-115777
Change-Id: I47e5d68afcba2c3b4203e4c0beded2e18ea2563b
Reviewed-by: Pasi Petäjäjärvi <pasi.petajajarvi@qt.io>
QFuture::then() uses QtPrivate::Continuation::create(), which in turn
uses private API from an inline function:
f->d.setContinuation(ContinuationWrapper(std::move(continuation)), fi.d);
f->d is QFutureInterfaceBase (a public class), but its setContinuation()
takes QFutureInterfaceBasePrivate by pointer. Our ELF versioning scripts
mark everything that uses that class as private, resulting in:
4806: 0000000000287d70 365 FUNC GLOBAL PROTECTED 16 _ZN20QFutureInterfaceBase15setContinuationESt8functionIFvRKS_EEP27QFutureInterfaceBasePrivate@@Qt_6_PRIVATE_API
This commit adds an exception for this symbol, causing it to go back to
the regular "Qt_6" ELF version:
5629: 00000000003d6a16 366 FUNC GLOBAL PROTECTED 16 _ZN20QFutureInterfaceBase15setContinuationESt8functionIFvRKS_EEP27QFutureInterfaceBasePrivate@@Qt_6
This solution can probably be cleaned up a bit by moving the marker into
the header files parsed by syncqt, so they follow code motion without
having to remember to update the CMakeLists.txt. That requires some
surgery with syncqt, so not suitable for cherry-picking.
As a drive-by, fix the target_type check
for the _qt_extra_linker_script_content genex property
Fixes: QTBUG-117514
Pick-to: 6.6
Change-Id: I85599ea5ca7a4b79a8bbfffd178b92e73dbe11de
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
A little code simplification. And we can enable exception handling
explicitly for GCC/Clang by adding "-fexceptions", it was missing
in the old code, add it as well.
[ChangeLog] [Build System] Qt explicitly pass -fexceptions now on
non-MSVC toolchains, if exception handling is not disabled in CMake
configure.
Change-Id: Id9d61d3ee8b7d490f4a743e34e8be321af080be0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
MSVC also supports "-w" since at least 2015:
https: //learn.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=msvc-140
Change-Id: If0775b1dd6e0785e2e42a25ed2b7f1346f7c345e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The QtQuick3D semi-public headers were not installed correctly due to a
typo in QtModuleHelpers. This amends 9c3c87f6d0
Change-Id: Iec6ed4e1785fbb1189385104f476c37481ef47fb
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
According to clang-cl documentation [1], when we need to pass
parameters to the clang driver, we need to add the "/clang:"
or "-Xclang" prefix to the parameter.
[1] https://clang.llvm.org/docs/UsersManual.html#the-clang-option
Change-Id: I2b96942a12fbdf70773c732c021e8ad5173e9311
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
clang-cl share many parameters with MSVC, but it makes the CMake code
complex. We temporarily remove the clang-cl compat code paths from the
MSVC code and they will be brought back in a central place in a separate patch.
Change-Id: I28b93c04d65e9a5133d61c7fbbdc5c83cc8cc37e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
clang-cl can't recognize the "-Ob3" parameter and it causes tons
warnings when compiling, just remove it if we are using clang-cl.
Change-Id: If50dccef15f771fc956eed218e97645d78d59073
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
I added this flag but only explained what it is in the original
commit message, it may confuse future code readers without some
inline comments. So add some comments to avoid such issue.
Change-Id: I6a3c0f53c2bc58646cc70e45cacb1d0e40656c0a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The Mimer SQL installation does not support universal binaries. Skip
building the Mimer SQL QtSql plugin when doing universal binary builds
of Qt for macOS
Change-Id: Ib0fad2d626fe65d886d5bf2f4848dda09bf65b14
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
qtypes.h defines qint128 and quint128 if __SIZEOF_128__ is defined.
VxWorks doesn't support 128bit ints (confirmed by the
WindRiver support team and by the fact that std::numeric_limits::is_specialized
returns false for those types), but clang defines that
symbol anyway.
-DQT_NO_INT128 is used to disable support for those types.
Task-number: QTBUG-115777
Change-Id: Iea024ad9e35734002ce516ebd8a7fa7f2352be62
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
In some corner-cases the header files are passed by symlink path
if the source directory is symlink. Make sure that we resolve symlinks
when running headersclean check.
Fixes: QTBUG-117518
Pick-to: 6.5 6.6
Change-Id: Ifaffc9186e78fba86037cb50438021466903d210
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The project has been superseded by Qt for WebAssembly and was
never supported in Qt 6.
Pick-to: 6.6 6.5
Change-Id: I36682cfe3ce6adac76a307b0faba97dcb7c655cc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The files generated by syncqt should land not only in module include
directory, but also in framework directory. Before syncqt made two
copies of the generated files one in staging directory and the second
one in module framework directory. This commit moves all logic related
to framework header files to cmake scripts. This is done for both
consistency and simlifying the logic. The whole module .syncqt_staging
directory is copying to the framework library in cmake.
[ChangeLog][Tools][syncqt] '-framework' and '-frameworkIncludeDir'
arguments were removed. The related logic is moved to cmake scripts.
Task-number: QTBUG-116483
Pick-to: 6.6 6.5
Change-Id: If79c5470d2ab51eb7fc083bce6fb01858bed76ba
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Features enable code coverage collecting using the gcov tool. The
resulting reports can then be post-processed by lcov or similar tools.
[ChangeLog][CMake][Coverage] Added the coverage configuration argument.
The only supported coverage tool at the moment is gcov. The argument
requires Qt is built in Debug otherwise setting the argument leads to
the configuration error. Typical usage:
<...>/configure -developer-build -coverage gcov
Task-number: QTBUG-86223
Change-Id: I39b2061f544997a7c4fe6f4d135c0ab447f15a17
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Use recursive descent to handle parentheses in config condition
expressions. This fixes cases like 'NOT (A AND B)'.
Fixes: QTBUG-117053
Change-Id: Iab1b6173abe00d763808bb972a9a5443ffa0938d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
By using a while loop instead of a foreach(RANGE), we can simplify the
code and remove the skipNext variable.
Also, we need to access the last used iteration index in a future
commit. This is not possible with a foreach loop without saving the
index in another variable.
Change-Id: I39306a0105fb31a6a8f39e9d4c47ee3424599a2b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
All of the continue() statements are not needed. There is no code after
the if-else chain.
Change-Id: I16188d14b4f05cb1e5f29bac4657149c4fce60a4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
The config.redo script can be executed to reconfigure a pre-existing
qt build dir with the configure options that were last passed to the
build.
It just calls the original configure script with the -redo option.
It's nicer than calling configure + -redo manually because you don't
need to write out the full source path for configure.
In qt 5 times this script was called config.status.
On windows the script is called config.redo.bat.
Rename the config.redo file that QtWriteArgsFile.cmake writes to
to config.redo.last, so it doesn't conflict with the name of new
config.redo script.
Amends 5c40cb0f1a
Pick-to: 6.5 6.6
Change-Id: Id47c56a24561410aec6fbaa79b13fc8a78d12ed0
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The qt_install() calls in qt_internal_add_test() did not re-create
subdirectories that are part of the input test data.
Make sure that the subdirectories are created upon installation by
ensuring we specify a relative installation path that includes all the
path parts except for the file name.
That works the same for directories.
Amends ec1546afc4
Amends 540bd6cf20
Amends 1307736c7d
Amends 0a1256a52d
Task-number: QTBUG-117098
Change-Id: Ia80f4e7e1ec531264864bcde3ac192ce79b65746
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Commit 946f15efb7 added the line
extern "C++" { std::* };
but that was too good to be true. The intention was to catch Standard
Library inline symbols that got emitted in our own libraries, not use of
Standard Library types in our symbols. Unfortunately, that glob
expression matches the demangling literally and return types for
templates are demangled in their usual position to the left of the
function name.
For example,
std::random_device qFoo(); // mangles as _Z4qFoov → "qFoo()"
but
template <typename T> T qFoo();
template std::random_device qFoo<std::random_device>();
mangles as _Z4qFooISt13random_deviceET_v and that demangles to
"std::random_device qFoo<std::random_device>()".
Therefore, we replace that with a full expansion according to the
mangling scheme. This includes a minor fix for the RTTI symbols, to
match nested names too (those with "N" in the name). It can't match
virtual override thunks ("Tv" and "Th"), because those have variable
length names and the matching is done by fnmatch(), not regex.
Pick-to: 6.6
Change-Id: I9d43e5b91eb142d6945cfffd178449cf68669cb6
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
[ChangeLog][CMake] Added variable QT_I18N_LANGUAGES to specify the
languages that are used for i18n in the project.
[ChangeLog][CMake] Added keyword I18N_LANGUAGES to
qt_standard_project_setup to conveniently set QT_I18N_LANGUAGES.
The call
qt_standard_project_setup(I18N_LANGUAGES hi ho)
sets the variable QT_I18N_LANGUAGES.
The target finalizers use this variable to set up CFBundleLocalizations
on Apple platforms.
qt_add_translations will be extended to read QT_I18N_LANGUAGES as well
to determine the names of .ts files if TS_FILES is not given.
Fixes: QTBUG-116716
Change-Id: I76f0753d10efb9c32947d9239e43382c9d85eb51
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Revert incidental change which leaked from dev environment.
It's better to save CI resources by only having one tab
opened in browser at a given time.
Change-Id: I7f8d1af546b749b2fec4f49a6751545f52c16414
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This is part of our testing effort where we try enabling more tests for
Web Assembly platform on CI. Not all tests work out of box, so some of
them will require followup work.
This commmit also introduces a new mechanism of automatically renaming
files when they are added many times with the same filename to single
translation unit.
Change-Id: I620536494ea83aeb9b294c4a35ef72b51e85a38b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
In a previous change, we ensured that all INPUT_foo cache variables are
unset at the end of configuration, so they don't influence feature
re-evaluation in case if a command line flag like -no-gui is not
specified upon second reconfiguration and a FEATURE_foo is manually
toggled in the CMakeCache.txt, effectively getting rid of
stale INPUT_foo values.
Unfortunately that causes an issue when configuring with -no-opengl
and then trying to reconfigure with 'cmake .'
Specifically various feature options like ENABLE / DISABLE use
INPUT_foo variables in their expressions.
qt_configure_add_report_entry CONDITIONs also use them.
These expect the INPUT_foo variables to be persisted, and if they are
removed, the expressions might be re-evaluated to a different value,
and cause re-configuration to fail or unexpectedly toggle features.
To support both cases described above, instead of removing all INPUT
variables when configuration ends, only unset those INPUT variables
whose corresponding FEATURE_foo variable has been manually toggled in
CMakeCache.txt or via an IDE.
Toggling a FEATURE_foo manually is intentional, which means the
INPUT_foo value should be discarded. Whereas pre-existing INPUT_bar
variables will persist, thus not breaking cases like the -no-opengl
report CONDITION.
Amends 2799391703
Pick-to: 6.6
Fixes: QTBUG-116973
Task-number: QTBUG-112957
Change-Id: I5851255bfa41a9a1d116630a5d9f7b9a74aa93ed
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Just some help to users, so they can spot the allowed values without
looking into docs.
Pick-to: 6.6
Change-Id: I22ad9533104949286de447a05a6e875e8d933bf6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
FindWrapOpenGL.cmake assumed that IMPORTED_LOCATION is the absolute path
of the library within the framework. That's not the case with CMake 3.28
anymore. There, IMPORTED_LOCATION is the absolute path of the framework
directory.
The relevant upstream CMake change is
6b01a27f901b5eb392955fea322cde44a1b782a3.
Pick-to: 6.2 6.5 6.6
Change-Id: I6b702a28318e0978c56dec83c398965aa77ef020
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Error is the default for this option in ld64, and with the new linker
in Xcode 15 the option was deprecated, causing a warning, so let's just
skip adding it and assume undefined symbols results in errors.
Fixes: QTBUG-116732
Pick-to: 6.6 6.5
Change-Id: I736a891ae102fe1dfb2cdf869f42c665e231adba
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Wiping of CMakeCache should lead to removing of CMakeCache that is
generated for configure-time executable. Otherwise configure-time
executables might still use wrong compiler or compiler flags.
Pick-to: 6.6 6.5
Task-number: QTBUG-116789
Change-Id: I702d5d29e0c5f35a8a36311cf9a84ea7a0f4d781
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For better integrations with Qt Creator, add a custom target with
the Jar files so they are shown under the project files. Since
source_group() is not supported, add_custom_target() is used.
Pick-to: 6.6 6.5
Change-Id: Ie527fdce918d526ee6e8953e27d4e0f4131a9828
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Make sure the Mimer SQL include files and libraries are found
to enable the Mimer SQL QtSql plugin.
Fixes: QTBUG-111219
Pick-to: 6.6
Change-Id: Ieee0e26f3689dd373fda81c98180066927d25b40
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It makes sense (in my opinion) to have the top-level CMakeLists.txt
to include and call certain commands that should be controlled by
qtbase, to avoid submodule update difficulties when we want to do
changes in qtbase that shouldn't concern the top-level file.
Create cmake/QtBaseTopLevelHelpers.cmake and move some pre-existing
code from the top-level CMakeLists.txt into separate functions that
are defined in qtbase.
This file will be included in the top-level one and said commands will
be called there.
This also prepares for qt_print_build_instructions not call
qt_internal_qt_configure_end anymore, because it will be called
by the top-level project.
Pick-to: 6.6
Change-Id: I1fe3490001cf441d742c64b2ef1f267cd4362f6a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Before this change, the dirty feature code only checked for
differences between FEATURE_foo and QT_FEATURE_foo, without taking
into account modified INPUT_foo values that might passed via the
configure script.
This led to issues in certain scenarios when reconfiguring with the
configure script.
For example configuring with -gui / -DINPUT_gui=ON and then with
-no-gui / -DINPUT_gui=OFF would fail saying
'Feature "widgets": Forcing to "ON" breaks its condition'
This happens because the widgets feature depends on gui being
available, but because INPUT_gui modifications don't trigger the dirty
feature re-eval code, we don't recompute the value of widgets.
Extract the code that takes into account the INPUT_foo variables into
a separate function, and use it both when computing feature values and
also when detecting dirty features.
This means any non-matching INPUT_foo variables will now also trigger
dirty feature checking.
Use the same function to replace the duplicate code we have to early
initialize the developer-build, no-prefix and pkg-config features.
Pick-to: 6.6
Task-number: QTBUG-112957
Change-Id: I775cf70b48291a659b0fecf7cb9570ec12735bca
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
To be able to reconfigure Qt with modified feature values using the
configure script, and take into account INPUT_foo values, we need to
ignore FEATURE_foo values. But we can't always ignore FEATURE_foo
values, because users might want to toggle them by editing
CMakeCache.txt or using an IDE.
What we can do is tell CMake we are configuring via the configure
script, in which case we can mostly be sure that any passed
INPUT_foo values should have higher priority than pre-cached
FEATURE_foo values.
We also need to remove all the cached INPUT_foo variables after they
have been used for feature computation, so that subsequent
reconfigurations where an INPUT_foo is not passed anymore, doesn't
cause a feature to accidentally reuse the previous (stale) value.
Pass -DQT_INTERNAL_CALLED_FROM_CONFIGURE=TRUE to CMake when configuring
via the configure script, and use that as a marker to make INPUT_foo
values have a higher priority.
This needs to be done centrally in qt_evaluate_feature and also in a
few more locations where we check INPUT_ values, like the developer
build and pkgconfig features.
Because QT_INTERNAL_CALLED_FROM_CONFIGURE would become a cached
variable, we want to remove it at the end of the configuration phase,
so that future 'cmake .' reconfigurations are not considered to be done
via configure.
To do that, we unset it right at the end of
qt_build_repo_end in a per-repo build, and in the final
qt_print_build_instructions call in a top-level build.
The latter needs a cleaner fix in follow up commits in qt5.git and
qtbase.
Pick-to: 6.6
Task-number: QTBUG-112957
Change-Id: I3fd338092041ef09e3f5a4dfbaf61da5deea0514
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Previously if Qt was configured with -developer-build, configure
would pass to CMake -DINPUT_developer_build=ON, which will ensure that
both FEATURE_developer_build and QT_FEATURE_developer_build are set to
ON.
Then if somebody tries to toggle FEATURE_developer_build to OFF in
the CMakeCache.txt and rerun cmake, the feature will bounce back to ON,
due to the code in QtSetup.cmake that doesn't take into account if
FEATURE_developer_build is already defined, and thus reset it based
on the value that is cached in INPUT_developer_build.
Change the checks for INPUT_developer_build and INPUT_no_prefix,
to take into account the defined-ness of their
FEATURE_ counterparts.
If they are defined, ignore the INPUT_ values.
This allows toggling the FEATURE_ variables and also aligns with
the INPUT_ handling behavior that we have in qt_evaluate_feature which
ignores INPUT_ values once the FEATURE_ is defined.
While this aligns the behavior with other features, there is still a
problem.
If you first configure without -developer-build,
and FEATURE_developer_build is set OFF, and then reconfigure with
-developer-build, because FEATURE_developer_build is already defined,
the INPUT_developer_build=ON is ignored.
This is a problem for other features as well and will be handled in a
follow up change.
Pick-to: 6.6
Task-number: QTBUG-112957
Change-Id: I4f31157b0e7963e4d43e28062a585e939ceea0c1
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
