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>
If source or build directry contain '3rdparty' in their path, all
header files are marked as 3rdparty and will never be installed.
This commit is CMake counterpart of
ea4a3d78a7
Amends ea4a3d78a7
Fixes: QTBUG-116137
Pick-to: 6.5 6.6
Change-Id: Ib93fb879867e3aeb6e44193c4253e73173c141d2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Case-insensitively match the architecture string for x86 and amd64.
Fixes: QTBUG-111219
Pick-to: 6.6
Change-Id: I775e81965f46bb7479e0e9a05e66b8a080656ee5
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In Qt 5 times, if Qt was configured with -make examples, running
make install would not only build and install the example binaries,
but would also install the example sources into the prefix.
Installation of example sources was not implemented when the Qt 6
build system has switched to using CMake.
There is still a use case for it though, mainly for Qt Creator, which
only shows the examples of a Qt kit if the sources are available.
In contrast to Qt 5, in Qt 6 we will not install example sources
by default. It will be opt in.
To enable installation of examples sources, configure with
configure -make examples -install-examples-sources
or
cmake -DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON
The -make examples part is required, otherwise
-install-examples-sources has no effect.
All example sources can be installed by calling
cmake --install . --component examples_sources
in the qt repo build directory.
In a top-level build, per-repo installation can be done using
cmake --install . --component examples_sources_<repo_name>
where repo_name could be 'qtbase'.
A single example's source can be installed by calling
cmake --install . --component examples_sources_<subdir_name>
where subdir_name is the subdirectory name of the example, e.g.
'gallery'.
Implement installation of example sources by hooking into the
qt_internal_add_example command.
This means that all examples in all repos need to be added via
qt_internal_add_example instead of add_subdirectory, to ensure the
sources are installed. The majority of repos already use it.
For testing purposes one can configure with
-DQT_BUILD_EXAMPLES=ON -DQT_INSTALL_EXAMPLES_SOURCES=ON
-DQT_INTERNAL_NO_CONFIGURE_EXAMPLES=ON to allow testing installation
of examples sources without building them.
Take into account an additional variable called
QT_INTERNAL_EXAMPLES_SOURCES_INSTALL_PREFIX to allow installation of
example sources into a location different from the example binaries.
As a cleanup, the NAME option that could previously be passed to
qt_internal_add_example_external_project has been removed.
That's because it's never used anywhere and could not have worked
anyway because qt_internal_add_example_in_tree never handled it.
Pick-to: 6.6
Fixes: QTBUG-112135
Change-Id: I52aa5ec643ff7e212276c88d8dd2dfecdbdbeb0d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
There's no guarantee that qconfig.h will be present
when __qt_internal_get_qt_build_emsdk_version() is called
during configure, since the file is written by a file(GENERATE)
call which does not write the file immediately.
Handle this case and allow configure to complete.
Change-Id: Iab85790f9f133fd1ba5f276cdd7bc55f9af1d980
Pick-to: 6.6
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Piotr Wierciński <piotr.wiercinski@qt.io>
If '-G<generator type>' is passed to configure script we should respect
this argument but not override it by the autodetected generator type.
'-cmake-generator' option will still have higher priority, but if
generator is set using CMake argument it will not be auto-detected by
other build config specific options, like '-debug-and-release'.
Change-Id: I75b49e33fa717f90bbd74045948fccb9f5350e8d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If user attempt to build Qt using multi-config generator set Release
and Debug configurations by default if they are not set, instead of
relying on what CMake suggests as default value for a platform.
Pick-to: 6.6
Change-Id: I4bdb33e56818984c189b737acccc9ac50659db96
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Currently QT_USE_QSTRINGBUILDER is added for all Qt module targets by
default, and it's not possible to remove this definition.
Replace this definition with the generator expression that is
propagated by the PlatformModuleInternal target.
Change-Id: I1c606e16809dc720e2eb72191e1670dfc48f1b48
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Currently QT_USE_QSTRINGBUILDER is added for all Qt tool targets by
default, and it's not possible to remove this definition.
Replace this definition with the generator expression that is
propagated by the PlatformToolInternal target.
Change-Id: Iac3bd3ea76e7b439cf7957146b4b6dd20ecdbe3a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The former implies the latter, so it makes little sense to treat them
differently. Even if some types of targets are (currently) never
compiled with PCH, users of qt_internal_all_x() shouldn't need to know
such details.
Pick-to: 6.6 6.5
Change-Id: I8ead238a8d9e55da632b2929638b67724a42d73c
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
