3 Commits

Author SHA1 Message Date
Joerg Bornemann
a9c18e5df2 CMake: Silence the private module warning for dependencies
If a private module package is pulled in by another Qt module we showed
the private module warning message. The user couldn't act on the warning
other than disabling it completely. This doesn't seem useful.

Now, we only show the warning if the user explicitly does
find_package(Qt6FooPrivate).

There's the situation where a private module is pulled in as dependency
and later pulled in by the user. For example, in a static Linux build
    find_package(Qt6 REQUIRED COMPONENTS Gui CorePrivate)
will pull in CorePrivate as transitive dependency of Gui's plugins.

To still see a warning for CorePrivate in this case we need to trigger
the warning in Qt6Config.cmake when handling the COMPONENTS.
To achieve that, the warning code has been moved to a function which is
called in Qt6Config.cmake and Qt6FooPrivateConfig.cmake

Task-number: QTBUG-87776
Change-Id: Ie9cc2d287d1fcb94db77045165f703cebcb6983d
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-02-12 10:26:05 +01:00
Joerg Bornemann
ad7b94e163 CMake: Only load Qt6FooPrivate automatically when building Qt
[ChangeLog][CMake] CMake packages of public Qt modules don't provide the
targets of their private counterparts anymore. User projects must now
call find_package(Qt6 COMPONENTS FooPrivate) to make use of the
Qt6::FooPrivate target. User projects that rely on the old behavior can
set the CMake variable QT_FIND_PRIVATE_MODULES to ON.

For user projects, the warning message we know from QMake is displayed.
The warning can be disabled by setting the CMake variable
QT_NO_PRIVATE_MODULE_WARNING to ON.

Within Qt itself, find_package(Qt6Foo) will still
find_package(Qt6FooPrivate).

For static Qt builds, we need to wrap usage of private Qt modules in
$<BUILD_INTERFACE> or $<BUILD_LOCAL_INTERFACE> (if CMake's version is >=
3.26). Static builds with CMake < 3.26 will always load the private
modules if the Qt6FooConfig.cmake from Qt's build tree is loaded. This
is the case in non-prefix builds and (in the future) when building
examples as external project.

This amends commit fbbf4ace0188b9718b6d7808021c0b887fd52d9f.

Pick-to: 6.9
Task-number: QTBUG-87776
Change-Id: I78e95248f2b3fa73c3005c61df2fe4f71ad8eeb8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
2025-01-24 18:53:34 +01:00
Joerg Bornemann
fbbf4ace01 CMake: Split off private module config packages
[ChangeLog][CMake] Private Qt modules have been split off into separate
Qt6FooPrivate CMake config packages. A call to find_package(Qt6Foo) will
now implicitly find_package(Qt6FooPrivate). It's not an error if
Qt6FooPrivate isn't available as it may be the case on certain Linux
distros that split their Qt module packages into private and public
parts.

For every public module Qt6Foo that has an associated Qt6FooPrivate
module, create a separate Qt6FooPrivate CMake config package.

Let Qt6FooPrivate find Qt6Foo. This is a required dependency.

Let Qt6Foo find Qt6FooPrivate if it's available. A message of log level
VERBOSE is issued if Qt6FooPrivate is not found.

Implementation notes: In QtModuleConfig.cmake.in, we pull in the private
module. This is not part of the *Dependencies.cmake file, because

1. The Qt6FooPrivate package references the Qt6::Foo target, therefore
it must be available. And Qt6FooDependencies.cmake is loaded before
creating targets.

2. The dependency needs to be optional, and we don't have facilities for
optional dependencies in Qt6FooDependencies yet.

3. We'd have to avoid recursion, because of the Qt6FooPrivate -> Qt6Foo
dependency.

Fixes: QTBUG-87776
Pick-to: 6.9
Change-Id: I8f23f07da7ca76486f87b759e197174c11e13534
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
2024-12-19 12:11:30 +01:00