| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 5ffc744b791a114a3180a425dd26e298f7399955
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>
|
|
|
Previously repo/tests/CMakeLists.txt was a standalone project on which
CMake could be called. This was useful for Coin to be able to build
and package only tests, but was a bit troublesome because that means
having to specify the usual boilerplate like minimum CMake version,
which packages to find in every tests.pro project.
Instead of having a separate standalone project, modify the top level
project and associated CMake code to allow passing a special
QT_BUILD_STANDALONE_TESTS variable, which causes the top level project
to build only tests, and find Qt in the previously installed qt
location.
This also means that when building a repo, we generate a
${repo_name}TestsConfig.cmake file which does find_package on all the
modules that have been built as part of that repo. So that when
standalone tests bare built for that repo, the modules are
automatically found.
qt_set_up_standalone_tests_build() is modified to be a no-op because
it is not needed anymore. Its usage should be removed from all the
other repos, and then removed from qtbase.
Non-adjusted tests/CMakeLists.txt projects in other repositories
should still be buildable with the current code, until they are updated
to the new format.
Adjust the Coin build instructions to build the standalone tests in a
separate directory.
Adjust pro2cmake to generate new structure for the tests/tests.pro
projects.
Adjust the qtbase tests project.
Fixes: QTBUG-79239
Change-Id: Ib4b66bc772d8876cdcbae1e90ce5a5a5234fa675
Reviewed-by: Qt CMake Build Bot
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
