Using this trick we force CMake xcode generator to give the more
specific project name when configuring standalone tests.
Change-Id: Ic679003c574c0407bdc8df9eecf3762db214fd50
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
If manual test target is created using the standard Qt API but not
qt_internal_add_manual_test command, we need initialize autotools
for these targets. Add the generic functionality that ensures that
autotools are inialized for all manual tests.
Pick-to: 6.5 6.6
Change-Id: Ic048760390174d1be2f01096d70e84458f1c870f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
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>
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>
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>
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>
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>
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>
Standalone test projects have the following condition in the
beginning of their project:
if(NOT QT_BUILD_STANDALONE_TESTS AND NOT QT_BUILDING_QT)
find_package(Qt6BuildInternals COMPONENT STANDALONE_TEST)
endif()
When configuring the project the first time, QT_BUILDING_QT is not
set, find_package is called, configuration succeeds.
But because standalone projects implicitly include QtSetup.cmake,
that file sets the QT_BUILDING_QT cache var to true, and upon test
reconfiguration, cmake errors out with:
Unknown CMake command "qt_internal_add_test"
or similar.
This happens because QT_BUILDING_QT is true on the second
reconfiguration and the find_package mentioned above is not executed
anymore, leading to unknown internal command errors.
Set a new QT_INTERNAL_IS_STANDALONE_TEST variable when we detect
a standalone test and check for its value in QtSetup so we don't
set QT_BUILDING_QT to TRUE anymore.
Adjust a few code locations where QT_BUILDING_QT being false might
trigger different behavior for standalone tests.
Task-number: QTBUG-93020
Change-Id: I5413b9f37653225175a1006f7626e023045b5979
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
The check_language macro spawns a new cmake subprocess to detect
availability of a language. We use that to detect availability of
the Objective-C/C++ languages when targeting Apple platforms.
That's problematic because the parent process CFLAGS / LDFLAGS env
vars influences the result of the subprocess compiler detection,
and in some cases that can fail the detection.
An example of that is passing iOS specific flags which then get
mixed with the default macOS flags added by CMake, resulting in
a linker failure.
Instead of using check_language, explicitly enable the Objective-C
and C++ languages when targeting Apple platforms because we know
that we need them for compiling Qt.
This avoids the issue because enable_language is not spawning a
separate cmake sub-process and thus passes more information to the
underlying try_compile project to ensure a successful check.
The change also means that CMake will error out earlier in case if the
Objective-C compiler is not found, which was not the case before.
Pick-to: 6.5 6.6
Fixes: QTBUG-114470
Change-Id: I1a16c1e5828dfe10b2d7da27cc9a8c787517ab8e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
We should sync external headers for 3rdpary projects
like freetype and harfbuzz-ng and keep the directory
structure.
Fixes: QTBUG-113416
Pick-to: 6.6 6.5
Change-Id: Ie66edb9a21cff37ca6c8c68b6d225de6d8bbad81
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
I think this needs to be more prominent, as I noticed during the testing
that it could cause issues if it gets lost in between the config
messages, as we knew of course.
Pick-to: 6.5 6.6
Task-number: QTBUG-113463
Change-Id: I2ece498a8d3604362a49cc10499b92b0d2764fb9
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
In cases where we allow symlink, we need to use ABSOLUTE path, and don't
resolve the symlink. This function returns ABSOLUTE only if we are on
Apple platform, and have QT_ALLOW_SYMLINK_IN_PATHS enabled. While this
is mainly to resolve the issue report by Homebrew, it might be useful if
a user really want to build with symlink.
Pick-to: 6.5
Task-number: QTBUG-113463
Change-Id: Ided141ed8de66cc1d3717ec2719eb703fa7fc589
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>
The macro sets the required CMake variables and policies and
should be called right after the
find_package(Qt6 COMPONENTS BuildInternals... call to make sure that
the subsequent code adopt all the required policies.
Pick-to: 6.5
Task-number: QTBUG-112685
Change-Id: I9f93f728ee4d8ae7743db9fffafa26025c76dcf2
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Like qt-configure-module.bat, when building with unity build, CMake
needs to know the full path of the source directory to be able to
correctly generate its `*_cxx.cxx` files. So far, this seems to only
affect Windows' LLVM/MinGW builds. By this patch, I make sure that we
pass the full path to CMake.
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: Ida2da127ecba95856b6e0091936c471c2a116936
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
- Removed the NO_UNITY_BUILD argument from commands that disable it by
default.
- Add a warning in case NO_UNITY_BUILD or NO_UNITY_BUILD_SOURCES is
being used where it is already disabled, e.g., qt_internal_add_test
- Exclude all sources of a target from unity build if NO_UNITY_BUILD
is set on the target. This sounds a bit harsh, but I have noticed that
sometimes the same source file can be included somewhere else, and
some unexpected collision may occur.
- qt_examples_build_end excludes all its examples from the unity build.
- qt_build_test now sets the CMAKE_UNITY_BUILD to OFF before configuring
the tests, and restore its value when done.
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: Ia42e7dd5a5bfb151db241deb639325720fd91eec
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When doing a top-level build with ExternalProject examples, it doesn't
make sense to make qtbase examples depend on e.g. qtdeclarative
plugins. Instead the qtbase example should only depend on plugins
built in qtbase.
Create per-repo custom targets that depend on all plugins built within
that particular repo.
Create an additional per-repo target which depends on all
plugins built in that repo, as well as plugins from dependent repos.
Use the latter as a dependency for examples built as part of the
current repo.
Repo dependencies are parsed from dependencies.yaml.
Pick-to: 6.5
Fixes: QTBUG-110913
Change-Id: I149860cc549caf53271c9ea296eb7bac2a663715
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This somewhat indicates the progress of configuring a specific
repo and the slower period of time when configuring examples
in-tree.
Pick-to: 6.5
Change-Id: I643536c4ebc865933730b7af2a1d0c56bbbf2912
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
AUTOUIC doesn't handle relative paths to .ui files in parent
directories when using Ninja Multi-Config.
The designer tool in qttools has such a ui file. This leads to the
following error when trying to build qttools together with examples as
ExternalProjects and Ninja Multi-Config:
ninja: error: 'src/designer/src/designer/designer_autogen/
include_Debug/ui_preferencesdialog.h', needed by
'src/designer/src/designer/designer_autogen:Debug',
missing and no known rule to make it
Until cmake is fixed, we can work around the issue by not adding
designer as a dependency when building EP examples, because no example
tries to use the app.
We can't exclude all apps from example dependencies because some
modules use qt_internal_add_app for tools as well, which are called
from public CMake API and also examples.
An example of this is qtapplicationmanager.
Given that we can't exclude all apps, introduce a function to
allow skipping single targets when building EP examples.
This will allow excluding designer specifically.
The examples will now depend on a new ${repo}_src_for_examples target
rather than ${repo}_src, which will exclude skipped targets.
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Task-number: QTBUG-110369
Change-Id: I2f900253bbf7bac917f2293ef604ab3ea8f298e1
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add it globally so that each module using tracepoints don't have to
add it themselves to each modules configure.cmake.
Pick-to: 6.5
Change-Id: Id58cfaff5cd715b2667da2470001d646117f9f28
Reviewed-by: Tomi Korpipää <tomi.korpipaa@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
qt-cmake-standalone-test uses add_subdirectory call when evaluating the
project. This leads to an error if users try to use path to
CMakeLists.txt as an argument, instead of directory when configuring
standalone tests with qt-cmake-standalone-test. It makes sense to check
if the user-specified path points to CMakeLists.txt and cut the
filename part when calling add_subdirectory.
Pick-to: 6.5 6.4 6.2
Change-Id: I6b9ac0ca8323eaf11f219eb1e6bed3057120a231
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
As far as I can tell nothing uses TYPE anymore.
[ChangeLog][QtCore][CMake] The deprecated TYPE option of the
qt_add_plugin() has been removed. You can specify the plugin
type using the PLUGIN_TYPE option instead.
Change-Id: I786fbc772a23ae0037d9a4cf68018e3af5cb061d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Building repo targets may be incomplete as we skip adding
INTERFACE_LIBRARIES as dependencies. This leads to the missing
artifacts belonging to HEADER_MODULES. It seems reasonable and safe to
include INTERFACE_LIBRARIES in the list of dependencies of the repo targets.
Pick-to: 6.4 6.2
Task-number: QTBUG-108815
Change-Id: I83f44018f42dcf2fb1e3299461e17ef53e79c2e5
Reviewed-by: Jörg Bornemann <joerg.bornemann@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>
If I understood the function correctly, then the example was not quite
right.
Change-Id: I6b6a4845c5ded2a058050dfbecf5db158d32d12a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Each module now identifies its actions during the configuration by a
prefix, e.g., `[QtBase]`. In addition,
- I have slightly modified some of the `message()` commands to get
a more coherent output.
- `syncqt.cpp` prints its output as WARNING if any
Change-Id: I3922d75a668d94f402068f4121751b7fcb6522b4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
As stated in `QtBuildInternalsConfig.cmake`, `cmake_minimum_required`
versions should be synced with `qtbase/.cmake.conf`, but it wasn't at
the moment.
Change-Id: I8100370778707d46abe973b681fd4aba182a7513
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
syncqt.pl adds an extra dependency on perl when building Qt. Modern C++
provides the convenient cross-platform way to access a filesystem and
to use regular expressions, so we may replace the perl script with C++
application. The syncqt executable is built at configure time and
installed as QtCore tool. It's running at configure time to deliver the
required header files for IDE to build a consistent code model and at
the build time to keep tracking changes in header files and generate
the missing aliases without reconfiguring. 'syncqt' only parses header
files from a CMake build tree, so the resulting Qt installation only
contains interfacing headers that belong to the platform that Qt is
built for. 'sync.profile' files are not used as the 'source of truth'
for sync qt procedure anymore, all the necessary information is taken
from either CMake files at configure time or from the module header
files while parsing them.
syncqt.pl is still in place since it's required as fallback solution
for a smooth transition to the new syncqt implementation for all qt
repositories.
This patchset only enables the C++ based syncqt for 'qtbase'
repository.
From the performance perspective C++ version works faster then perl
script, also the configure time is reduced significally on subsequent
reconfigurations - up x2 times faster when re-configuring repository,
but it also takes time to compile the tool itself the first time.
Numbers for qtbase:
syncqt.pl syncqt.cpp
initial: 0m16,035s 0m20,413s
reconfig: 0m6,819s 0m3,725s
The syncing procedure can be run separately for each module using
<ModuleName>_sync_headers targets. The 'sync_headers' target can be
used to sync all the modules at once.
Task-number: QTBUG-87480
Task-number: QTBUG-103196
Change-Id: I8c938bcaf88a8713b39bbfd66d9e7ef12b2c3523
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
We forwarded the compiler path to the EP but not the flags that might
have been set via the CXX environment variable.
Make sure to also forward the flags.
Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I0fbf9b595f7885014b1f09d158db52e56a3d5243
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
When building qtsvg examples as external projects on Windows
with Ninja Multi-Config in a prefix build on the CI, the build would
fail with an error message like:
ninja: error:
'C:/Users/qt/work/qt/qtsvg/lib/Qt6SvgWidgets.lib', needed by
'RelWithDebInfo/svgviewer.exe', missing and no known rule to make it
This can be reproduced locally on Windows if one calls
'ninja svgviewer' instead of just 'ninja'. I wasn't able to reproduce
it on macOS, although I have seen some peculiarities in the
dependencies there as well.
External project examples depend on the ${repo_name}_src custom
target to ensure all Qt modules are built, so one would expect that
dependency to be sufficient.
While trying to figure out what's going wrong, I noticed that running
'ninja -t query qtsvg_src:Debug' showed dependencies on Release
libraries, which should not happen. The :Release target looked fine
though.
I'm still not quite sure why the Release libraries are not built
on the first ninja run, despite the example having a proper dependency
on qtsvg:Release.
Running 'ninja svgviewer' a few more times ends up succeeding at one
point, because the SvgWidgets Release library does get built in
parallel with the failing example, and the next rebuild would
succeed.
While trying to fix the :Debug target to have proper dependencies, I
noticed that we add dependencies to the ${repo_name}_src custom target
via the DEPENDS option of add_custom_target(). That is incorrect,
that option should only be used for file level dependencies.
For target dependencies, add_dependencies should be used.
Doing that fixed both the :Debug dependencies as well as the Windows
issue, which is good enough for me.
Amends 08f46bb400
Pick-to: 6.2 6.3 6.4
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I1888681e2e9362d3237acbdacc83222d6a60b48e
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
When using qt-cmake-standalone-test, we didn't tell CMake to use the
same C++ language standard that Qt used when it was configured.
We did tell CMake to do that when configuring tests with
qt-internal-configure-tests via the qt_build_tests macro.
To ensure the proper standard is set, we also need to
find_package(Qt6Core), because the std flag is derived from the
QT_FEATURE_cxxyz flag which is set by Core.
Change-Id: Ia41f2a24983ddab0107a6446743f7b054df8c033
Pick-to: 6.2 6.3 6.4
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Add an option to limit the number of tests for building and testing
Android multi-ABI configurations in CI. Currently only Core tests
supposed to run.
Change-Id: Ibb8a41d60d108259ef2675ec54bde2482f87c8b2
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
In cross-compilation, the CMAKE_FIND_ROOT_PATH will have path to the
host Qt and examples build will pick up wrong Qt6Config.cmake unless
the build dir path is prepended.
Pick-to: 6.4 6.3 6.2
Fixes: QTBUG-104270
Change-Id: I7fc7499369a2e5446e1c5257155f81c72716fef7
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When recording which package version to look for in
QtFooModuleDependencies.cmake and other files like it,
instead of using PROJECT_VERSION, use the version of the
package that contains the dependency.
For example if we're hypothetically building the qtdeclarative repo
from the 6.4 branch, against an installed 6.2 qtbase, then
the Qt6QmlModuleDependencies.cmake file will have a
find_package(Qt6Core 6.2) call because qtdeclarative's
find_package(Qt6Core) call found a 6.2 Core when it was configured.
This allows switching the versioning scheme of specific Qt modules
that might not want to follow the general Qt versioning scheme.
The first candidate would be QtWebEngine which might want to
follow the Chromium versioning scheme, something like
Qt 6.94.0 where 94 is the Chromium major version.
Implementation notes.
We now record the package version of a target in a property
called _qt_package_version. We do it for qt modules, plugins,
3rd party libraries, tools and the Platform target.
When we try to look up which version to write into the
QtFooModuleDependencies.cmake file (or the equivalent Plugins and
Tools file), we try to find the version
from a few sources: the property mentioned above, then the
Qt6{target}_VERSION variable, and finally PROJECT_VERSION.
In the latter case, we issue a warning because technically that should
never have to happen, and it's a bug or an unforeseen case if it does.
A few more places also need adjustments:
- package versions to look for when configuring standalone
tests and generating standalone tests Config files
- handling of tools packages
- The main Qt6 package lookup in each Dependencies.cmake files
Note that there are some requirements and consequences in case a
module wants to use a different versioning scheme like 6.94.0.
Requirements.
- The root CMakeLists.txt file needs to call find_package with a
version different from the usual PROJECT_VERSION. Ideally it
should look for a few different Qt versions which are known to be
compatible, for example the last stable and LTS versions, or just
the lowest supported Qt version, e.g. 6.2.6 or whenever this change
would land in the 6.2 branch.
- If the repository has multiple modules, some of which need to
follow the Qt versioning scheme and some not,
project(VERSION x.y.z) calls need to be carefully placed in
subdirectory scopes with appropriate version numbers, so that
qt_internal_add_module / _tool / _plugin pick up the correct
version.
Consequences.
- The .so / .dylib names will contain the new version, e.g. .so.6.94
- Linux ELF symbols will contain the new versions
- syncqt private headers will now exist under a
include/QtFoo/6.94.0/QtFoo/private folder
- pri and prl files will also contain the new version numbers
- pkg-config .pc files contain the new version numbers
- It won't be possible to write
find_package(Qt6 6.94 COMPONENTS WebEngineWidgets) in user code.
One would have to write find_package(Qt6WebEngineWidgets 6.94)
otherwise CMake will try to look for Qt6Config 6.94 which won't
exist.
- Similarly, a
find_package(Qt6 6.4 COMPONENTS Widgets WebEngineWidgets) call
would always find any kind of WebEngine package that is higher than
6.4, which might be 6.94, 6.95, etc.
- In the future, if we fix Qt6Config to pass EXACT to its
subcomponent find_package calls,
a find_package(Qt6 6.5.0 EXACT COMPONENTS Widgets WebEngineWidgets)
would fail to find WebEngineWidgets, because its 6.94.0 version
will not be equal to 6.5.0. Currently we don't pass through EXACT,
so it's not an issue.
Augments 5ffc744b79
Task-number: QTBUG-103500
Change-Id: I8bdb56bfcbc7f7f6484d1e56651ffc993fd30bab
Reviewed-by: Michal Klocek <michal.klocek@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Turning off pkg-config with the configure flag -no-pkg-config did not
work. There are different defaults for FEATURE_pkg_config on different
platforms (e.g. Linux: ON, Windows: OFF). The existing code that
calculated the initial FEATURE_pkg_config value assumed that the default
is OFF and never turned the feature off.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-104123
Change-Id: I33b9687c55c60d4ec9224324951a8838741ee976
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Otherwise they will just use default compiler
Pick-to: 6.3
Change-Id: Id5813b99fbbb6b0d8b0ee658e06312b637a097c1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Allow such a combination
- staging prefix (CMAKE_STAGING_PREFIX / -extprefix) set to the
qtbase build dir
- install prefix (CMAKE_INSTALL_PREFIX / -prefix / on-device prefix) set
to some custom location
even for non-cross builds.
An example would be
configure -prefix /usr \
-extprefix ~/qt/qtbase_build_dir
CMake will put the Qt libraries in the qtbase build dir, ninja install
will not be required, but ultimately in order to run applications,
the Qt libraries are expected to be in /usr.
Support for this scenario was originally added for cross-builds in
062318feb2 , but not desktop builds.
Such a build is useful when you want to have install rpaths different
from where Qt is initially installed to (the staging prefix).
This case doesn't really happen often when targeting desktop
platforms, it's mostly used for cross-compilation (e.g yocto).
Being able to have the same setup with a desktop build is nevertheless
useful for faster iteration on build system issues in such a scenario.
Amends 062318feb2
Pick-to: 6.2 6.3
Change-Id: I42be3628a30025f14eebaf0a79401b54e95cde26
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Originally, QT_INTERNAL_EXAMPLES_INSTALL_PREFIX was added to
control the installation of examples when they are built as
ExternalProjects, and was not considered for the non-EP case because
we hoped to switch entirely to EP-based building.
Due to some unsolved issues regarding using EP builds in CI, add the
ability to control the installation of non-EP examples.
This will be used in the CI to allow removing the hacky
INSTALL_EXAMPLEDIR and INSTALL_EXAMPLESDIR assignments in example
projects.
It is also likely that we will not deprecate the non-EP based
building, because it is useful for IDE integration (EP targets
are not as developer-friendly to work with in an IDE in regards
to rebuilding).
Amends 98c89c8cc1
Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I02264aaa1daa2c80bb9ef3d02b1831b4ca5d2b84
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
to QT_INTERNAL_EXAMPLES_INSTALL_PREFIX so it's clear that the
variable only affects the location of where examples
are installed.
And make sure the paths are passed as CMake paths.
Amends 1031fa1547
Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: Ib92c55488b736d980da2bd88255de78e183de824
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
