Commit Graph

153 Commits

Author SHA1 Message Date
Joerg Bornemann
b1aa6c2bc8 CMake: Fix early exit in qt_build_repo_post_process()
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>
2023-08-24 15:14:53 +02:00
Joerg Bornemann
d5c4d6eb77 CMake: Rename QT_EXAMPLES_CMAKE_PREFIX_PATH
...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>
2023-08-23 16:21:58 +02:00
Joerg Bornemann
2ab80a2c18 CMake: Allow find_package(Qt6 COMPONENTS Foo) in tests
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>
2023-08-23 16:21:58 +02:00
Joerg Bornemann
b684984939 CMake: Fix find_package(Qt6*Tools) in non-qtbase tests
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>
2023-08-23 16:21:58 +02:00
Joerg Bornemann
e05b779c88 CMake: Don't create superfluous qtrepo_XXX_for_examples targets
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>
2023-08-21 08:35:52 +02:00
Joerg Bornemann
ba96238600 Fix running CMake test projects in prefix builds
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>
2023-08-19 11:03:36 +02:00
Alexandru Croitor
121f7f382b CMake: Allow installation of example sources into the Qt prefix
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>
2023-08-16 19:04:40 +02:00
Alexandru Croitor
961ff0cc8a CMake: Don't use check_language for Objective-C/C++
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>
2023-06-29 16:28:53 +02:00
Alexey Edelev
65b0bc0eed Fix external header support in qtsync
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>
2023-06-09 13:42:05 +00:00
Amir Masoud Abdol
9a5de496f1 Move QT_ALLOW_SYMLINK_IN_PATHS warning to config.summary
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>
2023-06-08 19:29:34 +02:00
Amir Masoud Abdol
672a1d022c Implement qt_internal_get_file_path_mode for changing the file path mode
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>
2023-05-31 16:37:25 +02:00
Alexey Edelev
18ef6849d2 Add the list of previously searched packages to qt_find_package
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>
2023-05-26 17:44:54 +02:00
Alexey Edelev
f3c10280f5 Introduce the qt_internal_project_setup macro
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>
2023-04-24 14:20:25 +02:00
Amir Masoud Abdol
684d301983 Disable Unity Build for Examples
Pick-to: 6.5
Task-number: QTBUG-109394
Change-Id: I20999512e557db618c14e36d62317680bc17c43a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2023-04-06 14:28:24 +01:00
Amir Masoud Abdol
3602936230 Improve the internal handling of unity build
- 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>
2023-03-14 17:28:44 +01:00
Alexandru Croitor
a804ac3d88 CMake: Relax example dependencies to be per-repo
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>
2023-03-06 18:54:00 +01:00
Alexandru Croitor
4a4c329687 CMake: Show a message when configuring examples
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>
2023-02-07 18:27:11 +01:00
Alexandru Croitor
4e70ab5eeb CMake: Work around AUTOUIC Ninja Multi-Config issue with EP examples
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>
2023-01-20 18:21:46 +01:00
Antti Määttä
bab65d70dc Add find package for lttng library so that it gets added to target
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>
2023-01-13 12:43:45 +02:00
Amir Masoud Abdol
d8abcc969b Remove the deprecated TYPE option from qt_add_plugin
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>
2022-12-07 06:09:15 +00:00
Alexey Edelev
ada76ac8b6 Add INTERFACE_LIBRARIES to dependencies of repo targets
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>
2022-12-01 02:23:52 +01:00
Amir Masoud Abdol
60968090ad Update -redo option such that it removes CMakeCache.txt and CMakeFiles/
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>
2022-12-01 02:23:51 +01:00
Alexandru Croitor
6847a19e3e CMake: Reconfigure faster by not looking for missing packages
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>
2022-11-29 12:43:46 +01:00
Amir Masoud Abdol
c675c1c56d Fix a mistake in the documentation of qt_internal_read_repo_dependencies
If I understood the function correctly, then the example was not quite
right.

Change-Id: I6b6a4845c5ded2a058050dfbecf5db158d32d12a
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-11-26 11:23:13 +01:00
Amir Masoud Abdol
5fcfacdb7f Use CMAKE_MESSAGE_CONTEXT for Better CMake Output Messages
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>
2022-10-25 23:24:30 +02:00
Amir Masoud Abdol
ef822cf03d Sync CMake Version with .cmake.conf
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>
2022-10-25 18:14:35 +00:00
Alexey Edelev
b89d63515b Replace the syncqt.pl script with syncqt tool
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>
2022-09-27 13:12:11 +02:00
Lucie Gérard
32df595275 Change the license of all CMakeLists.txt and *.cmake files to BSD
Task-number: QTBUG-105718
Change-Id: I5d3ef70a31235868b9be6cb479b7621bf2a8ba39
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-08-23 23:58:42 +02:00
Alexandru Croitor
7fb25609a4 CMake: Fix examples to build as external projects when cross-compiling
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>
2022-08-05 16:41:04 +02:00
Alexandru Croitor
0e2f218ee7 CMake: Fix Ninja Multi-Config dependency issues for top-level targets
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>
2022-08-05 16:41:04 +02:00
Lucie Gérard
fb1b20eab3 Add license headers to cmake files
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>
2022-08-03 17:14:55 +02:00
Alexey Edelev
5fc8a377ce Build minimal subset of tests for Android multi-ABI Qt builds
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>
2022-08-02 21:18:50 +02:00
Samuli Piippo
18ed6a8979 CMake: prepend build dir for examples build
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>
2022-07-21 11:54:47 +02:00
Alexandru Croitor
dd1030a450 CMake: Record used package version for each target dependency
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>
2022-07-01 10:50:57 +02:00
Joerg Bornemann
4cef4f1c1b Make configure -no-pkg-config actually work
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>
2022-06-10 14:11:09 +02:00
Allan Sandfeld Jensen
c164b75c17 Pass compilers on to examples configs
Otherwise they will just use default compiler

Pick-to: 6.3
Change-Id: Id5813b99fbbb6b0d8b0ee658e06312b637a097c1
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-04-26 22:58:56 +02:00
Alexandru Croitor
f3483e6b96 CMake: Allow no install + custom on-device prefix for desktop builds
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>
2022-04-19 17:20:14 +02:00
Alexandru Croitor
9a18facc66 CMake: Allow specifying custom install dir for non-EP examples
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>
2022-04-04 15:41:20 +02:00
Alexandru Croitor
33f631920f CMake: Rename QT_INTERNAL_CUSTOM_INSTALL_DIR
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>
2022-04-04 15:41:20 +02:00
Alexandru Croitor
c926ef55de CMake: Allow passing -v to ninja when building examples as EPs
By default when building ExternalProjects, even if the main ninja
invocation has -v passed, that won't be passed to the nested ninja
calls.

When building examples in the CI, we want to see the full command line
invocations.

Allow passing -v to the nested EP ninja calls by configuring Qt with
-DQT_INTERNAL_VERBOSE_EXAMPLES=ON, which we will use in our CI.

We don't want to add -v by default because if the main ninja does not
have one, the nested calls will still be verbose.

Pick-to: 6.2 6.3
Change-Id: Ifd4b312c6eaa7354e8870f4fb0a77fadf0f33ab7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-04-04 15:41:20 +02:00
Alexandru Croitor
939a8281e6 CMake: Fix picking of the binary_for_strip project location
Fix binary_for_strip project not being found when the following
conditions were met:
- building a repo other than qtbase
- qtbase sources are not available on the machine
(usually happens in CI where only the current repo sources are
available).

The issue was that QT_CMAKE_DIR would always be defined, regardless of
which repo was being built and the system would incorrectly assume
the location of the project files.

The fix is to always pick up the sources from qtbase's source dir if
they are available (this time done with an appropriate check),
otherwise use the installed files.

Note that the behavior of always using the qtbase sources if available
is not exactly the best, but it is a more general issue that affects
other code too.
In the name of consistency, make it so for the binary_for_strip
project as well, but add TODOs in code to address the situation
in a separate change.

Amends 39f657032b

Pick-to: 6.2 6.3
Fixes: QTBUG-102064
Task-number: QTBUG-88090
Task-number: QTBUG-101653
Change-Id: I0649f945e9ff0ab1f597c51bb5ab389fa665c021
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-29 14:56:14 +02:00
Christophe Giboudeaux
8924cc13be CMake: Don't hardcode the library directory name
Using INSTALL_LIBDIR is the only reliable way to get the library install directory.

Amends: d1c56073b4

Pick-to: 6.2 6.3
Change-Id: Ib8c4fb8b4d339c63209393d7fdb3d1c3425b03a4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2022-03-29 00:16:54 +01:00
Alexandru Croitor
39f657032b CMake: Generate and use a wrapper script for stripping binaries
MinGW 11.2.0 comes with a strip.exe that strips the ".gnu_debuglink"
section in binaries, a section that is needed for the separate debug
information feature.

binutils version 2.34 mentions the feature for the first time:
https://sourceware.org/binutils/docs-2.34/binutils/strip.html#strip

To ensure the debuglink section is preserved, generate a shell wrapper
that calls the original strip binary with an extra option to keep the
required section.

To determine if the option is supported, we build a real shared library
on which strip will be called with the --keep-section option.
If the option is not supported, a wrapper is not generated and the
stock strip binary is used.

This logic only applies when targeting Linux and MinGW + a shared
library Qt. For other targets, the stock strip binary is used.

Developers can opt out of this logic by passing
-DQT_NO_STRIP_WRAPPER=TRUE when configuring each Qt repo.

Pick-to: 6.2 6.3
Fixes: QTBUG-101653
Change-Id: Idd213d48d087d3c9600c853362aebaba348cde33
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-24 21:50:50 +01:00
Alexandru Croitor
70c3dd4a54 CMake: Enable verbose autogen for cmake auto tests and EP examples
So we can see the exact moc invocations when debugging issues in the
CI.

For ExternalProject examples, it is conditional on whether Qt is
configured with QT_INTERNAL_VERBOSE_EXAMPLES set to ON, otherwise
calling the main ninja without -v will end up cluttering the output
with AUTOGEN output.

Pick-to: 6.2 6.3
Change-Id: I6468ab0e461b3be283e2428e3515cae4d5986242
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-24 21:50:50 +01:00
Alexandru Croitor
64d5708458 CMake: Enable debug verbosity for cmake auto tests and EP examples
Since e2a0ddbb69 , if Qt is configured
as a non-developer-build, some of the CMake tests that include QtSetup
would have their CMAKE_MESSAGE_LOG_LEVEL set to the reduced NOTICE
value.
Make sure that tests always have a DEBUG level, so that if they fail
in the CI, we have more info on what goes wrong.

For ExternalProject examples, it is conditional on whether Qt is
configured with QT_INTERNAL_VERBOSE_EXAMPLES set to ON, otherwise
calling the main ninja without -v will end up cluttering the
output a non default log level.

Amends e2a0ddbb69

Pick-to: 6.2 6.3
Change-Id: Icd3b6e0fcc6c73e4b53b6c4a6d8354c96077a050
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-24 21:50:50 +01:00
Alexandru Croitor
d1c56073b4 CMake: Don't rely on CMAKE_FIND_ROOT_PATH_MODE_PACKAGE for examples
We shouldn't set CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to BOTH when
cross-building examples without ExternalProjects.

Instead append the $build_tree_prefix to CMAKE_FIND_ROOT_PATH
and $build_tree_prefix/lib/cmake to QT_EXAMPLES_CMAKE_PREFIX_PATH
to circumvent the usual CMake path-rerooting issue.

This ensures that the build-tree Config files are found by the in-tree
find_package calls when cross-building examples.

Pick-to: 6.2 6.3
Task-number: QTBUG-96232
Change-Id: I4e31f0bf3dbfeb4339823fe09addda3ae83f12c3
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-16 15:56:17 +01:00
Alexandru Croitor
c89da21249 CMake: Fix cross-building examples in prefix builds as ExternalProjects
For examples to successfully find not yet installed Config files in a
prefix cross-build, both CMAKE_FIND_ROOT_PATH and CMAKE_PREFIX_PATH
need to be adjusted when toolchain files set
CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY.

Before this change, we lacked two things.

1) If the chain-loaded toolchain file sets CMAKE_FIND_ROOT_PATH
(instead of appending), then the initial value of CMAKE_FIND_ROOT_PATH
that was passed by ExternalProject's initial cache would be
overridden.

2) The prefixes we passed via QT_EXAMPLES_CMAKE_PREFIX_PATH did not
end in lib/cmake, to work around the path re-rooting problem in CMake.

We can handle both of these points by using
QT_ADDITIONAL_PACKAGES_PREFIX_PATH which was introduced for Conan
usage.

Each value assigned to QT_ADDITIONAL_PACKAGES_PREFIX_PATH
gets prepended to CMAKE_FIND_ROOT_PATH by qt.toolchain.cmake AFTER the
original toolchain file is chain-loaded.

And each value also gets lib/cmake appended and assigned to
both CMAKE_PREFIX_PATH and _qt_additional_packages_prefix_paths (used
by Qt6Config.cmake.in to work with find_package + NO_DEFAULT_PATH).

This is exactly what we need to ensure examples build.

Pick-to: 6.2 6.3
Task-number: QTBUG-96232
Change-Id: I11a52457ff795a6661a3a7b68e823e0615d0ce89
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-03-16 15:56:16 +01:00
Alexandru Croitor
92dff7c5f8 CMake: Handle slashes in qt_internal_add_example
qtdeclarative has a call like
 qt_internal_add_example(imagine/automotive)

This causes issues when trying to pass that as the name of the
external project. Use the last part after the last slash as the name
of the project.

Pick-to: 6.2 6.3
Change-Id: Ifc074e50e537f07f3636699ed255d2561930d873
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2022-02-09 16:48:25 +01:00
Alexandru Croitor
1031fa1547 CMake: Allow installing examples outside of the Qt prefix
Introduce a new QT_INTERNAL_CUSTOM_INSTALL_DIR variable to
allow specifying an 'examples install dir' outside of the Qt prefix.

It will be used in a follow-up change to ensure we don't package
the example binaries in our CI artifacts (thus saving space).

This will be even more important when the examples will contain code
to deploy Qt libraries alongside each deployed example (which would
significantly increase the package size).

Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I06b4a8f9e8c57a712a356bca0f5c351a9362bc30
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
2022-02-01 16:51:01 +01:00
Alexandru Croitor
98c89c8cc1 CMake: Build examples as ExternalProjects in prefix builds
Change prefix builds to use ExternalProjects to build examples
by default. This will affect our CI which only does prefix builds.

To make it work, we have to do a few adjustments:
- look for Config files in the build-tree (before Qt is installed)
- build only one examples with only a single config,
   even if Qt is a multi-config build
- install examples as part of main make install step, rather than
  as part of the make step (which is the default for EPs)
- adjust CXX flags when building with MSVC to ensure we can still
  use sccache and separate debug info
- derive the correct install prefix for each example and pass it
  to the ExternalProject

As a drive-by, add TODOs to address tidiness of the code and corner
cases that likely don't work (Conan).

Amends d97fd7af2b

Pick-to: 6.2 6.3
Task-number: QTBUG-90820
Task-number: QTBUG-96232
Change-Id: I3060da5dc64e7b06052f9dcb720d4d250f876450
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
2022-02-01 16:51:01 +01:00