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>
Before this change, if a user toggled a FEATURE_foo variable, we only
recomputed the value for dependent features who's CONDITION would break
with the new value. If the CONDITION was not broken, the dependent
feature value would remain unchanged.
For example if FEATURE_developer_build was OFF, and the user
toggled it to ON, the FEATURE_private_tests value would remain OFF,
because OFF is a valid value for private_tests' CONDITION.
But we would like FEATURE_private_tests to become ON if we toggled
FEATURE_developer_build to ON.
To address this case, we need to recompute features who's dependent
feature values have changed.
The algorithm introduced by this change is:
- keep track of initial dirty features, aka track when FEATURE_foo is
different from QT_FEATURE_foo. We expect FEATURE_foo to be the
variable that a user toggles in the cache file or an IDE.
- when evaluating feature values, collect feature dependencies from
the various expressions given to options like CONDITION, AUTODETECT
- if any feature dependency is marked dirty, reset the feature value
to its auto-computed value and mark the reset feature as dirty
- repeat for all feature evaluations
Because feature evaluation is eagerly recursive, we will successfully
reset all features that need resetting.
To ensure against unforeseen breakages, allow disabling this behavior
by configuring with -DQT_NO_FEATURE_AUTO_RESET=ON
Adjust some of the messages to contain more details.
Note that the pre-existing behavior of resetting feature values when
the condition can't be satisfied, stays. For example if
FEATURE_developer_build is OFF and FEATURE_private_tests is manually
toggled to ON, it will reset to OFF
because its condition can't be satisfied (developer_build is still
OFF).
Amends 61943aefd6
[ChangeLog][Build System] The build system will now try to recompute
configure features when dependent feature values are toggled by the
user.
Pick-to: 6.6
Fixes: QTBUG-96936
Task-number: QTBUG-85962
Task-number: QTBUG-112957
Task-number: QTBUG-116209
Change-Id: Ib627f3675df8a3b08f4936cdc9c51f2d6e15f58c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
It makes more sense for it to live next to the other feature code.
Pick-to: 6.6
Task-number: QTBUG-96936
Task-number: QTBUG-85962
Task-number: QTBUG-112957
Task-number: QTBUG-116209
Change-Id: I8438e6fce9deaa5e709e4b0e2e1ea4eb0600a89a
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Follow the same patterns as for qpa and rhi. Semi-public APIs will be
put under the "namespace" ssg which is short for Spatial Scene Graph.
Taks-number: QTBUG-116570
Change-Id: I38887f129ec90e67f6a929a0d8ea5ea8b8c49ee8
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
If we configure module that is already installed it's expected that
tests use the build directory to resolve all the depdencies, but not
the install directory. This is especially sensetive if the module cmake
scripts were changed.
This changes the order of find_<package|dependency> PATHS that are
used to locate Qt package. QT_EXAMPLES_CMAKE_PREFIX_PATH now is used at
first, so we guarantee that we look into the build directory at
first place. This trick only works if build directory is added to
CMAKE_FIND_ROOT_PATH. The reason for that is the internal CMake logic
that tries to relocate the search PATHs and put the paths that are
subdirs of or exact CMAKE_FIND_ROOT_PATH higher in search list.
Fixes: QTBUG-115730
Change-Id: Icab721f0a6eac7301c626350ab214cc4545b368b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We've had issues in the past where Standard Library constructs either
with or without a Qt type mangled in the middle get exported from our
ABI and thus get marked with the Qt version numbers. For example, I can
see in our libraries:
517: 000000000010e608 24 OBJECT GLOBAL DEFAULT 22 typeinfo for std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>@@Qt_6
615: 00000000000eb2a0 47 OBJECT GLOBAL DEFAULT 17 typeinfo name for std::_Mutex_base<(__gnu_cxx::_Lock_policy)2>@@Qt_6
706: 000000000010e5f8 16 OBJECT GLOBAL DEFAULT 22 typeinfo for std::_Mutex_base<(__gnu_cxx::_Lock_policy)2>@@Qt_6
750: 00000000000ed5f0 16 OBJECT GLOBAL DEFAULT 17 std::_Sp_make_shared_tag::_S_ti()::__tag@@Qt_6
754: 00000000000da408 1 OBJECT GLOBAL DEFAULT 17 std::piecewise_construct@@Qt_6
This causes user content to break when an update to Qt stops exporting
such symbols, either because of code changes or because of changes to
the compiler and its optimizer.
In fact, this commit will cause that, for the symbols above. But this
will no longer be random-looking.
[ChangeLog][Important ABI Changes] On ELF-based platforms (e.g., Linux,
FreeBSD), the linking process has been updated to exclude Standard
Library symbols from getting the "Qt_6" ELF version. This solves the
problem of applications and libraries breaking arbitrarily after Qt
updates, but will cause such breakages right now. Content built with
older versions of Qt may need to be relinked.
Change-Id: I5acc02341c5940499682fffd1775edce0021ce6d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This also removes the configure option and therefore makes the feature
not disable-able. Saves 350 ms of CMake time.
Change-Id: Ifbf974a4d10745b099b1fffd17775528767595d4
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This is a macro. We cannot use return() here or we're skipping code at
the call site.
This commit amends b684984939.
Task-number: QTBUG-88264
Change-Id: Icf6dd06338584239873bf4d66a4bbceef9071399
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
...to QT_BUILD_CMAKE_PREFIX_PATH, because the variable is now used for
examples and tests.
Change-Id: Ie6d32a0c99f46407f2771e12638456078c59fb18
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
In prefix builds of non-qtbase repositories, calls to find_package(Qt6
COMPONENT Foo) did not work in tests, because the find_package calls in
Qt6Config.cmake use NO_DEFAULT_PATH, and thus CMAKE_PREFIX_PATH is
ignored.
Non-external-project examples had the same problem. This was fixed by
ffe0889413 which introduced the variable
QT_EXAMPLES_CMAKE_PREFIX_PATH as additional parameter in all relevant
find_package calls.
We now set this variable in qt_build_tests where it should be local to
the tests directory and its children.
We cannot use QT_ADDITIONAL_PACKAGES_PREFIX_PATH, because it's value is
read once and cached in Qt6Config.cmake - we would have to clear the
internal cache variable.
It would probably be good to rename QT_EXAMPLES_CMAKE_PREFIX_PATH to
reflect that it's not just used for examples. However, my naming skills
are drained for today.
Task-number: QTBUG-88264
Change-Id: I8bcfe9b7f2ee1f1b75dc725977924d09cb36822c
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Tests in non-qtbase modules could not find_package their own Qt6*Tools
packages, because add_subdirectory(tests) was called before the config
files for Qt6*Tools were created.
The creation of tools config files is done in QtPostProcess.cmake, which
was included in qt_build_repo_end(). Move that include into its own
macro, qt_build_repo_post_process() and remove it from
qt_build_repo_end(). Call qt_build_repo_post_process() before the
'tests' directory is added in qt_build_repo().
Every call site of qt_build_repo_end() must now be adjusted and call
qt_build_repo_post_process().
Task-number: QTBUG-88264
Change-Id: I80d60a1b5c0e9b715c298ef4934b562f815432d1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When using MinGW compiler and Qt is configured with "-static-runtime",
we should pass "-static" to g++ while linking, like Qt 5, instead of
"-Wl,-Bstatic", to get rid of dependencies on libgcc_s_seh-1.dll,
libwinpthread-1.dll and libstdc++-6.dll.
Because syncqt doesn't link to any Qt library,
"target_link_options(${target} INTERFACE -static)" has no effect on it.
So we should use "PRIVATE" instead of "INTERFACE" for executables.
Pick-to: 6.6 6.5
Change-Id: Icf551783f92ef3615b3840c9af16d163eee09fdb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Only create a qtrepo_src_for_examples target that examples, built as
external projects, can depend on.
Change-Id: I334bc67b9b78f49d5c345cb256132f42dc2c5f5e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Consider the following situation: There are CMake tests in
qttools/tests/auto/cmake that configure and build CMake test projects,
essentially as external projects. One of those test projects does
find_package(Qt6 COMPONENTS LinguistTools). This call fails in a prefix
build, because Qt6LinguistToolsConfig.cmake is not installed yet. It
merely exists in qttools-build/lib/cmake/Qt6LinguistTools.
We must adjust CMAKE_PREFIX_PATH to be able to find Qt6LinguistTools. We
also must adjust QT_ADDITIONAL_PACKAGES_PREFIX_PATH to be able to find
the LinguistTools component of the Qt6 package.
Use the prefixes setup from the support for building examples as
external projects and use it for CMake test projects as well.
Task-number: QTBUG-84884
Change-Id: I1bd5d5084cf931196bdb014cd75ca7578cd9decb
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The density of Q_FOREACH uses in this and some other modules is still
extremely high, too high for anyone to tackle in a short amount of
time. Even if they're not concentrated in just a few TUs, we need to
make progress on a global QT_NO_FOREACH default, so grab the nettle
and stick to our strategy:
Mark the whole of Qt with QT_NO_FOREACH, to prevent new uses from
creeping in, and whitelist the affected TUs by #undef'ing
QT_NO_FOREACH locally, at the top of each file. For TUs that are part
of a larger executable, this requires these files to be compiled
separately, so add them to NO_PCH_SOURCES (which implies
NO_UNITY_BUILD_SOURCES, too).
In tst_qglobal.cpp and tst_qcollections.cpp change the comment on the
#undef QT_NO_FOREACH to indicate that these actually test the macro.
Task-number: QTBUG-115839
Change-Id: Iecc444eb7d43d7e4d037f6e155abe0e14a00a5d6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
