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>
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>
When configuring Qt the second time it might be situation that
the set of qt_find_package calls is changed. One of the scenarios
is the changing of the submodule list that needs to be built in
top-level builds. It's also applicable for Qt features that lead to
extra package lookup in the unlocked subdirectories. Current approach
collects packages that were found at the previous run and skips
search of the packages that are missing. The problem is that
it also skips packages even if qt_find_package was not called at
previous run. QT_INTERNAL_PREVIOUSLY_SEARCHED_PACKAGES collects
all packages that were actually searched at the previous run
to make sure that qt_find_package don't skip packages that
appeared at second run only.
Note: Described scenarios may still have other issues and are not
tested well.
Fixes: QTBUG-113244
Pick-to: 6.5
Change-Id: Iab36060a28fbaa16a3b3bdba67795955c496b0c3
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Cleanup the generated message regarding the configuration summary. Also
moved the flushing into the helper function.
Pick-to: 6.5
Change-Id: I45728ac5b43613f002b6d5b07b9ad037416c4fff
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
This replaces the qt_parse_all_arguments macro with the built-in
`cmake_parse_arguments(PARSE_ARGV`. In addition, a new function,
_qt_internal_validate_all_args_are_parsed, can be used to check whether
any _UNPARSED_ARGUMENTS have been passed to the function.
Fixes: QTBUG-99238
Change-Id: I8cee83dc92dc6acdaaf747ea6ff9084c11dc649b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In the case of re-doing, `configure` and `configure.bat` pass an extra
parameter to the `QtProcessConfigureArgs.cmake`. As a result, CMake
removes CMakeCache.txt and CMakeFiles/ before the reconfiguration. If
the user is using CMake 3.24 or newer, this is achieved by passing
the `--fresh` option to CMake call. In older CMake(s), CMakeCache.txt
and CMakeFiles/ found in CMAKE_BINARY_DIR will be removed using a
file(REMOVE_RECURSIVE call.
[ChangeLog] The -redo option now additionally removes existing
CMakeCache.txt file, and CMakeFiles/ directory, and recreates them from
scratch.
Task-number: QTBUG-108287
Change-Id: I11a5c8f9df1247d11eb7097552e6764463583346
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Instead of constantly trying to find packages by calling
qt_find_package on each reconfiguration, record which packages were
found during initial configuration. Then on a second reconfiguration,
skip looking for packages that were not found on the initial
configuration.
This speeds up reconfiguration on certain platforms and repos.
Here are some stats for my macOS qtbase build.
not skip 3.69s user 4.96s system 98% cpu 8.750 total
skip 2.69s user 1.00s system 97% cpu 3.792 total
Top-level build with -submodules=qtquick3d
not skip 15.03s user 10.58s system 97% cpu 26.334 total
skip 13.87s user 5.16s system 96% cpu 19.724 total
Note this is a behavior change from how find_package is used in most
CMake projects, where if a package was previously missing, the
developer can just install the package and reconfigure to pick it up.
With this change, they will first have to remove their CMakeCache.txt
file and configure from scratch, or remove the
QT_INTERNAL_PREVIOUSLY_FOUND_PACKAGES cache variable and reconfigure.
For this reason, we enable this behavior by default only in
-developer-builds.
Builders can also opt in or out by setting the
QT_INTERNAL_SAVE_PREVIOUSLY_FOUND_PACKAGES variable to either ON or
OFF.
Note this behavior does not apply to user projects, or direct
find_package calls (as opposed to qt_find_package).
Fixes: QTBUG-107251
Change-Id: Iee9c5d120eb09e2a94eebb059a2174ef6b241e03
Reviewed-by: Kai Köhne <kai.koehne@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@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>
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>
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>
message(STATUS) prints output to a buffered stdout, whereas
message(NOTICE) or just message() print to unbuffered stderr.
We use a mix of message() calls when printing the configuration
summary, which caused interleaved output.
Because CMake offers no message(FLUSH), we work around the issue
by calling execute_process(COMMAND -E echo " ") which does
call std::cout << s << std::flush;
We seem to have to do it twice, before and after the
detailed configuration summary is printed.
Pick-to: 6.2 6.3
Change-Id: Ibc075551fc0547073f0696477e54d9b9c1edca97
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
CMake has logic to rewrite build rpaths that contain
CMAKE_STAGING_PREFIX to instead point to CMAKE_INSTALL_PREFIX.
This breaks running executables from the build directory, because
their build rpath will point to a location where the libraries might
not exist yet (we didn't install Qt yet).
Work around this by setting CMAKE_STAGING_PREFIX to a fake path, so
that CMake does not do the rewriting anymore.
CMAKE_STAGING_PREFIX needs to be set at subdirectory scope, not
function scope, which is why
qt_internal_apply_staging_prefix_build_rpath_workaround() is a macro
that is called from within each Qt internal function that creates
a target.
The workaround can be disabled by configuring with
-DQT_NO_STAGING_PREFIX_BUILD_RPATH_WORKAROUND=ON
The downside of this workaround is that it breaks per-subdirectory
install rules like 'ninja src/gui/install'.
Regular global installation like 'ninja install' works fine.
This is similar to what we do for tests in
qt_set_up_fake_standalone_tests_install_prefix()
introduced by 20292250d4
The reason it's not as good for other target types is because in
contrast to tests, we do want to install them.
In case if someone does call `ninja src/gui/install' they will most
likely get a permission error, telling them it's not possible to
install into
/qt_fake_staging_prefix/
check_qt_internal_apply_staging_prefix_build_rpath_workaround
Fixes: QTBUG-102592
Change-Id: I6ce78dde1924a8d830ef5c62808ff674c9639d65
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Otherwise we get:
Styles ................................. Basic Fusion Imagine iOS
Material Universal macOS Windows
-- Qt is now configured for building. Just run 'cmake --build .
--parallel'
Pick-to: 6.2 6.3
Change-Id: Ie8d009455e4f45c9eb0557c4a08e9d0a94030c3a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
when configuring for the first time.
Also mention how to increase output verbosity.
Unfortunately there is no way to check what is the current log
verbosity to only show the latter message conditionally.
Setting --log-level does not assign the same value to
CMAKE_MESSAGE_LOG_LEVEL.
Amends e2a0ddbb69
Pick-to: 6.2 6.3
Change-Id: I22101b9dc7c407cc54aa5e7964dec50c7490f8f5
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Only show the more verbose configure output when configuring
with -developer-build (which matches --log-level=STATUS)
Otherwise in a non-developer build, restrict the output
to NOTICE+ message (includes WARNINGs and ERRORs).
Developers can still pass a custom log level when configuring.
For example -DCMAKE_MESSAGE_LOG_LEVEL=STATUS or
--log-level=STATUS.
The former method will be cached, while the latter is only applied
to the current configure invocation.
Also show the build instructions hint message only when configuring
for the first time.
[ChangeLog][CMake][configure] The configure output verbosity of
non developer-builds of Qt is now reduced by default. Pass
"-- --log-level=STATUS" to configure to make it verbose again.
Pick-to: 6.2 6.3
Change-Id: I7583a9c92142e0b1d7c5411b06403f40d8ebaf20
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Minor glitch in wording, but it's been bugging me for months.
The meaning of "try to remove [a file]" implicitly says you might be
unable to do so; while the attempt might help with your situation, the
experiment might merely be a diagnostic, e.g. because if you can't
remove the file, that would imply things that would help you solve
your problem. For contrast, "try removing [a file]" says removal
might actually solve the problem for which this action is proposed as
a fix.
Change-Id: Ic995cfdef1523094bb368dcda8bd0d2bbd2e9434
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This hasn't worked for some time. It's not in our CI and I don't think
it was working at all. When I tried to build it, I ran into several
problems with C++17 and an Internal Compiler Error I did not have any
interest in working around.
After discussing with the Intel compiler team, it was decided that
fixing those issues in the old compiler is not going to happen. Instead,
their recommendation is to adopt the new LLVM-based compiler, which
the last commit added support for.
This commit does not remove qmake support for the old ICC. It's possible
someone is using qmake with a non-Qt6 project and ICC.
Change-Id: Icb2516126f674e7b8bb3fffd16ad6350ddbd49e5
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This includes a few cleanups to our .cmake files where it was easier to
combine existing sections of Clang / AppleClang that no longer needed to
be distinct.
icpx could be replaced with a shell script:
exec `basename $0`/clang++ --intel "$@"
tst_qnumeric is not passing
FAIL! : tst_QNumeric::classifyF() Compared values are not the same
Actual (qFpClassify(tiny / two)): 2
Expected (FP_SUBNORMAL) : 3
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(344)]
FAIL! : tst_QNumeric::classifyD() Compared values are not the same
Actual (qFpClassify(tiny / two)): 2
Expected (FP_SUBNORMAL) : 3
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(344)]
FAIL! : tst_QNumeric::floatDistance(denormal) Compared values are not the same
Actual (qFloatDistance(from, stop)): 0
Expected (expectedDistance) : 4194304
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(408)]
FAIL! : tst_QNumeric::doubleDistance(denormal) Compared values are not the same
Actual (qFloatDistance(from, stop)): 0
Expected (expectedDistance) : 2251799813685248
Loc: [/home/tjmaciei/src/qt/qt6-icx/qtbase/tests/auto/corelib/global/qnumeric/tst_qnumeric.cpp(408)]
P
Change-Id: Icb2516126f674e7b8bb3fffd16ad59431e8c3379
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This will show packages that were found (or not) with
find_package(QUIET) in summary just before the configure summary.
It's useful for CI logs to determine whether some Qt packages was not
found when cross-compiling.
Pick-to: 6.2
Change-Id: Ic7d5062cf061f7c60b5c74374f957065dd8029f5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The configure summary now suggests "ninja install" for Ninja
Multi-Config builds, because "cmake --install ." does not install all
configurations. See CMake upstream issue #21475.
Pick-to: 6.2
Change-Id: Ie3129a906945db9d09c6772ce66ec7239797b8fc
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Otherwise it will confusingly only list the host arch
Pick-to: 6.2
Change-Id: Ic6d080f1fd9ebfa260ce7c35bd5e5b4ee686f083
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
With the existing types we can only display a list of features or
whether a feature is on or off, but we cannot display arbitrary values.
Using the new message type, it is possible to show paths or versions as
summary entries.
Change-Id: I5d16cb4b30923f3566755bd4d7440bdd1ece82f5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add an optional argument to store the report command while feature
evaluation-only stage. This is necessary, because according to the
actual feature evaluation process, evaluation happens only once and it's
impossible to record any command during the evaluation-only stage.
Fixes: QTBUG-90319
Change-Id: I215fbe0a28a2661cd2d97d253b2e2c787d295cbd
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Jason McDonald <macadder1@gmail.com>
Add output of feature condition error at the end of configuration
summary. Introduce qt_configure_add_report_error that may be used
to add error to end-point configure report without actual
configure interruption.
Fixes: QTBUG-88282
Change-Id: Idcf478da863ae6507438eb3370927d7d1f01e071
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This reverts commit 642ee46f98.
Reason for revert: Issue when command_count is actually 0
Pick-to: 6.0
Change-Id: I1b2603f25b56e3bd50cfc22a08925930ad231498
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Use LESS_EQUAL condition since qt_configure_command_count stores last
added command index but not actual count
Fixes: QTBUG-88054
Pick-to: 6.0
Change-Id: I8112820f9885bdad5a786a4f6b4890d8f2fbe14b
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Extend qt_configure_get_padded_string to make the feature list look like
qmake's.
Fixes: QTBUG-88144
Change-Id: I714f2b2f3537b506365a03b5b6bc3413e9cab167
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
For non-cross-builds, qt-configure-module is located in
CMAKE_INSTALL_PREFIX/bin, not below the staging prefix.
Fixes: QTBUG-88262
Change-Id: Ib6cdd88ece391d5b8ce850b991564e5bed1e475d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
...instead of qt-cmake-private.
Also, add ".bat" on Windows.
Change-Id: I2aa94ac76f2dadfb8e94d68b19bb379b3d45a93d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This makes the diff-ing of the config summary between qmake and CMake
builds correct.
Change-Id: I720b69572c23afd78e6d0bea6cdf0740980c3b36
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
This automatically sets the CMake Generator to be the same as the one
used for qtbase.
Change-Id: If9e1a6942520417393055c572f0d892efca43d2e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The path was wrong if CMAKE_STAGING_PREFIX was set.
Change-Id: Iec90c7a5edf0da80a0ac108fe3411c340c01e9a9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When doing a top-level build,
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX is not set in the
top-level scope. There's no point really in using the relocatable
path anyway, given this will only be displayed once when either
configuring qtbase or qt6.
Just use CMAKE_INSTALL_PREFIX directly.
Change-Id: Idb7e1953745f55048c42155868c2dd9384876c7c
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Aka handle CMAKE_INSTALL_PREFIX in a more relocatable way.
The following story inspired this change.
If a user wants to build a Qt repo into a different install prefix
than the usual Qt one, this will fail configuration because we
look for various things like syncqt, qdoc, etc relative to
CMAKE_INSTALL_PREFIX, which will now point to a different location
where none of the above tools are located.
The intent for such a use case is to support building Qt packages with
Conan, which sets a random install prefix when configuring a repo.
The idea is to derive the qt prefix dynamically from the
QtBuildInternals package location. Essentially it's a reverse relative
path from the QtBuildInternalsConfig.cmake file to the install prefix
that was specified when initially configuring qtbase.
Once the dynamic prefix is computed (so we know where the possibly
relocated Qt is), we can find tools like syncqt and qdoc.
This is an initial attempt to support a use case like that.
More design work will probably needed in case if tools / libs need to
be found in a location different than the Qt install prefix (so
support for multiple install prefixes / search paths).
An example of such a case would be when building qtdeclarative and
qtquickcontrols2 as Conan packages in one go. Most likely the
qmltyperegistrar tool will be located in the random install prefix
set by Conan, so building qtquickcontrols2 might fail due to not
finding the tool in the original Qt install prefix.
As to the implementation details, the change does the following:
- Dynamically computes and sets the
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX variable when
find_package()'ing QtBuildInternals. It's an absolute path
pointing to where the relocated Qt is.
- When building qtbase this variable is not yet available (due
to QtBuildInternalsExtra not existing), in that case we set
the variable to the absolute path of CMAKE_INSTALL_PREFIX
(but only for the initial qtbase configuration).
- Remove QT_BUILD_INTERNALS_ORIGINAL_INSTALL_PREFIX which was used
for standalone tests purposes. It's not needed now that we compute
the location of the Qt prefix dynamically.
- The Unixy qt-cmake and qt-cmake-private shell scripts now
use a relative path to find the toolchain file we created.
- The toolchain file also dynamically computes the location of the Qt
packages, and adds them to CMAKE_PREFIX_PATH.
- A lot of existing CMAKE_INSTALL_PREFIX uses are replaced with
QT_BUILD_INTERNALS_RELOCATABLE_INSTALL_PREFIX. This includes finding
tool locations, mkspecs dir, path environment setup for tools, etc.
- Some places still use CMAKE_PREFIX_PATH in the following cases
- When determining paths while configuring qtbase (valid cases)
- When I wasn't sure what the behavior should be, so I left them
as-is (an example is documentation generation, do we want to
install it into the random Conan prefix, or into the main prefix?
Currently it installs in the random prefix).
Note that relocating a Qt installation does not work for non-prefix /
non-installed builds, due to hardcoded paths to include directories
and libraries in generated FooTargets.cmake files.
Task-number: QTBUG-83999
Change-Id: I87d6558729db93121b1715771034b03ce3295923
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Like libs, tools, examples, tests. Built by default means
they are part of the default make / ninja target.
Change-Id: I304e5724fc5dbd39626e9d589a6e1e92a4dd7882
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Teaches configurejson2cmake about summaries / reports, so things
like enabled features, configure sections, notes, etc.
Add relevant CMake API for adding summary sections and entries,
as well as configure reports. The commands record the passed data,
and the data is later evaluated when the summary needs to be printed.
This is needed, to ensure that all features are evaluated by the
time the summary is printed.
Some report and summary entries are not generated if they mention a
feature that is explicitly exclduded by configurejson2cmake's feature
mapping dictionary. This is to prevent CMake from failing at configure
time when trying to evaluate an unknown feature. We should re-enable
these in the future.
A few custom report types are skipped by configurejson2cmake (like
values of qmake CONFIG or buildParts).
These will have to be addressed a case-by-case basis if still needed.
Change-Id: I95d74ce34734d347681905f15a781f64b5bd5edc
Reviewed-by: Leander Beernaert <leander.beernaert@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
