Debian Bug report logs - #1087385
qt6-declarative-dev depends on qt6-declarative-private-dev

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: cmake 3.31.0-1 breaks Qt6Qml builds

Date: Tue, 12 Nov 2024 18:43:25 +0200

Package: cmake
Version: 3.31.0-1
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>
Control: affects -1 qt6-declarative-dev src:kf6-baloo src:kf6-bluez-qt src:analitza

https://buildd.debian.org/status/logs.php?pkg=kf6-bluez-qt&ver=6.6.0-2
https://buildd.debian.org/status/logs.php?pkg=kf6-baloo&ver=6.6.0-2
https://buildd.debian.org/status/logs.php?pkg=analitza&ver=4%3A24.08.2-2

...
CMake Error in src/imports/CMakeLists.txt:
  Imported target "Qt6::QmlPrivate" includes non-existent path

    "/usr/include/x86_64-linux-gnu/qt6/QtQml/6.7.2"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.



CMake Error in src/imports/CMakeLists.txt:
  Imported target "Qt6::QmlPrivate" includes non-existent path

    "/usr/include/x86_64-linux-gnu/qt6/QtQml/6.7.2"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.
...



This seems to be coming from
/usr/lib/x86_64-linux-gnu/cmake/Qt6Qml/Qt6QmlTargets.cmake
in qt6-declarative-dev.


I haven't investigated whether cmake or qt6-declarative is the
package that needs fixing.

Message #12 received at 1087385@bugs.debian.org (full text, mbox, reply):

From: Hefee <hefee@debian.org>

To: Adrian Bunk <bunk@debian.org>, 1087385@bugs.debian.org

Subject: Re: Bug#1087385: cmake 3.31.0-1 breaks Qt6Qml builds

Date: Wed, 13 Nov 2024 14:19:10 +0100

[Message part 1 (text/plain, inline)]

Hey,

> This seems to be coming from
> /usr/lib/x86_64-linux-gnu/cmake/Qt6Qml/Qt6QmlTargets.cmake
> in qt6-declarative-dev.

ACK this file has the missing path. I started to investigate it in kf6-kcmutils 
a bit and the problem is the macro qt6_add_qml_module.

the usage in  autotests/kconfig_compiler/CMakeLists.txt triggers it:

qt6_add_qml_module(test15qml URI "org.kde.kconfig.test15" QML_FILES 
Test15Qml.qml)

it boils down to  the macro _qt_internal_target_enable_qmlcachegen that 
includes Qt6::QmlPrivate, that reads Qt6QmlTargets.cmake.

(As workaround I can install qt6-declarative-private-dev and it compiles).

On the other side the macro is used successfully in src/qml/CMakeLists.txt via 
ecm_add_qml_module ( but no qml files are added) and this compiles without any 
error:

qt6_add_qml_module(KF6ConfigQml URI "org.kde.config")

Than I tested to downgrade cmake to testing:

The issue does not happen, when I use cmake 3.10.5.

3.31.0 does  care about non existing directories in 
INTERFACE_INCLUDE_DIRECTORIES 
3.30.5 do not care about non-existing directories.

Regards,

hefee

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 1087385@bugs.debian.org (full text, mbox, reply):

From: Brad King <brad.king@kitware.com>

To: 1087385@bugs.debian.org

Cc: Adrian Bunk <bunk@debian.org>, Hefee <hefee@debian.org>

Subject: Re: Bug#1087385: cmake 3.31.0-1 breaks Qt6Qml builds

Date: Wed, 13 Nov 2024 08:49:58 -0500

On Wed, Nov 13, 2024 at 8:24 AM Hefee wrote:
> 3.31.0 does  care about non existing directories in
> INTERFACE_INCLUDE_DIRECTORIES
> 3.30.5 do not care about non-existing directories.

I don't think that specific diagnostic has changed.
With this example:

```
cmake_minimum_required(VERSION 3.30)
project(DebianIssue1087385)
find_package(Qt6 REQUIRED COMPONENTS Qml)
add_executable(main main.cxx)
target_link_libraries(main PRIVATE Qt6::QmlPrivate)
```

both CMake 3.31.0 and 3.30.5 show:

```
CMake Error in CMakeLists.txt:
  Imported target "Qt6::QmlPrivate" includes non-existent path

    "/usr/include/x86_64-linux-gnu/qt6/QtQml/6.7.2"

  in its INTERFACE_INCLUDE_DIRECTORIES.
```

This was reported to Ubunu long before 3.31 came out:

* https://bugs.launchpad.net/ubuntu/+source/qt6-declarative/+bug/2054914

If 3.30.5 works and 3.31.0 fails, something else has changed
behavior that leads to this symptom.

-Brad

Message #22 received at 1087385@bugs.debian.org (full text, mbox, reply):

From: Timo Röhling <roehling@debian.org>

To: 1087385@bugs.debian.org

Cc: Brad King <brad.king@kitware.com>, Adrian Bunk <bunk@debian.org>, Hefee <hefee@debian.org>

Subject: Re: Bug#1087385: cmake 3.31.0-1 breaks Qt6Qml builds

Date: Wed, 13 Nov 2024 15:50:17 +0100

[Message part 1 (text/plain, inline)]

Hi Brad,

On Wed, 13 Nov 2024 08:49:58 -0500 Brad King <brad.king@kitware.com> 
wrote:
> If 3.30.5 works and 3.31.0 fails, something else has changed
> behavior that leads to this symptom.
The offending include path in 
/usr/lib/x86_64-linux-gnu/cmake/Qt6Qml/Qt6QmlTargets.cmake is 
guarded by a generator expression which checks the condition

$<BOOL:$<TARGET_PROPERTY:Qt6::Qml,_qt_module_has_private_headers>>

Maybe something changed in the way generator expressions are handled 
during target import?


Cheers
Timo


-- 
⢀⣴⠾⠻⢶⣦⠀   ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling                                       │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯

[signature.asc (application/pgp-signature, inline)]

Message #27 received at 1087385@bugs.debian.org (full text, mbox, reply):

From: Hefee <hefee@debian.org>

To: 1087385@bugs.debian.org, Brad King <brad.king@kitware.com>

Cc: Adrian Bunk <bunk@debian.org>

Subject: Re: Bug#1087385: cmake 3.31.0-1 breaks Qt6Qml builds

Date: Wed, 13 Nov 2024 17:28:21 +0100

[Message part 1 (text/plain, inline)]

Hey,

> ```
> cmake_minimum_required(VERSION 3.30)
> project(DebianIssue1087385)
> find_package(Qt6 REQUIRED COMPONENTS Qml)
> add_executable(main main.cxx)
> target_link_libraries(main PRIVATE Qt6::QmlPrivate)
> ```
> 
> both CMake 3.31.0 and 3.30.5 show:

ACK that fails here, too.

But if I do (with an empty test.qml): 

```
cmake_minimum_required(VERSION 3.30)
project(DebianIssue1087385)
find_package(Qt6 REQUIRED COMPONENTS Qml)
qt_standard_project_setup(REQUIRES 6.5)
qt6_add_qml_module(main URI "test" QML_FILES test.qml)
```

If parses fine with 3.30.5 and fails with 3.31.0. 

the call stack so far I understood:
qt6_add_qml_module ->  _qt_internal_target_enable_qmlcachegen that calls ( 
Qt6QmlMacros.cmake line 12250):
    target_link_libraries(main PRIVATE
        Qt6::QmlPrivate
        Qt6::Core
    )

I added a message cmd before to see, that it is triggerd and the arguments.

Okay there is something going on that stopped the error to bubble up on 
3.30.5.

Regards,

hefee

[signature.asc (application/pgp-signature, inline)]

Message #32 received at 1087385@bugs.debian.org (full text, mbox, reply):

From: Brad King <brad.king@kitware.com>

To: 1087385@bugs.debian.org

Cc: Adrian Bunk <bunk@debian.org>, Hefee <hefee@debian.org>

Subject: Re: Bug#1087385: cmake 3.31.0-1 breaks Qt6Qml builds

Date: Wed, 13 Nov 2024 11:38:04 -0500

On Wed, Nov 13, 2024 at 11:28 AM Hefee wrote:
> But if I do (with an empty test.qml):
> ...
> If parses fine with 3.30.5 and fails with 3.31.0.

Thanks!  With that I can reproduce the problem locally.
I'll track it down.

-Brad

Message #37 received at 1087385@bugs.debian.org (full text, mbox, reply):

From: Brad King <brad.king@kitware.com>

To: 1087385@bugs.debian.org

Cc: Adrian Bunk <bunk@debian.org>, Hefee <hefee@debian.org>

Subject: Re: Bug#1087385: cmake 3.31.0-1 breaks Qt6Qml builds

Date: Wed, 13 Nov 2024 15:23:14 -0500

On Wed, Nov 13, 2024 at 11:38 AM Brad King wrote:
> > If parses fine with 3.30.5 and fails with 3.31.0.
> I can reproduce the problem locally.  I'll track it down.

The change in behavior is due to CMake 3.31 fixing this bug:

* https://gitlab.kitware.com/cmake/cmake/-/issues/25728

Here is a simple example:

```
cmake_minimum_required(VERSION 3.30)
project(DebianIssue1087385 C)
add_library(iface INTERFACE IMPORTED)
set_property(TARGET iface PROPERTY INTERFACE_INCLUDE_DIRECTORIES
"/does/not/exist")
add_executable(main main.c)
target_link_libraries(main PRIVATE iface)
```

With both 3.30.5 and 3.31.0 the simple example correctly fails:

```
CMake Error in CMakeLists.txt:
  Imported target "iface" includes non-existent path

    "/does/not/exist"

  in its INTERFACE_INCLUDE_DIRECTORIES.
```

However, if one adds the code:

```
target_include_directories(main PRIVATE
"$<TARGET_PROPERTY:iface,INTERFACE_INCLUDE_DIRECTORIES>")
```

then 3.30.5 incorrectly works due to the above-linked bug.
3.31.0 fixes that bug and now produces the correct diagnostic.

In Qt6Qml, `Qt6QmlMacros.cmake` adds that extra line in
the end of the `_qt_internal_qml_type_registration` function:

```
   target_include_directories(${effective_target} PRIVATE
         $<TARGET_PROPERTY:${QT_CMAKE_EXPORT_NAMESPACE}::QmlPrivate,INTERFACE_INCLUDE_DIRECTORIES>
    )
```

-Brad

Message #42 received at 1087385@bugs.debian.org (full text, mbox, reply):

From: Alexandru Croitor <alexandru.croitor@qt.io>

To: "1087385@bugs.debian.org" <1087385@bugs.debian.org>

Subject: Re: Bug#1087385: cmake 3.31.0-1 breaks Qt6Qml builds

Date: Thu, 14 Nov 2024 11:08:48 +0000

On Wed, 13 Nov 2024 15:23:14 -0500 Brad King <brad.king@kitware.com> wrote:
> On Wed, Nov 13, 2024 at 11:38 AM Brad King wrote:
> > > If parses fine with 3.30.5 and fails with 3.31.0.
> > I can reproduce the problem locally.  I'll track it down.
> 
> The change in behavior is due to CMake 3.31 fixing this bug:
> 
> * https://gitlab.kitware.com/cmake/cmake/-/issues/25728
> 
> Here is a simple example:
> 
> ```
> cmake_minimum_required(VERSION 3.30)
> project(DebianIssue1087385 C)
> add_library(iface INTERFACE IMPORTED)
> set_property(TARGET iface PROPERTY INTERFACE_INCLUDE_DIRECTORIES
> "/does/not/exist")
> add_executable(main main.c)
> target_link_libraries(main PRIVATE iface)
> ```
> 
> With both 3.30.5 and 3.31.0 the simple example correctly fails:
> 
> ```
> CMake Error in CMakeLists.txt:
>   Imported target "iface" includes non-existent path
> 
>     "/does/not/exist"
> 
>   in its INTERFACE_INCLUDE_DIRECTORIES.
> ```
> 
> However, if one adds the code:
> 
> ```
> target_include_directories(main PRIVATE
> "$<TARGET_PROPERTY:iface,INTERFACE_INCLUDE_DIRECTORIES>")
> ```
> 
> then 3.30.5 incorrectly works due to the above-linked bug.
> 3.31.0 fixes that bug and now produces the correct diagnostic.
> 
> In Qt6Qml, `Qt6QmlMacros.cmake` adds that extra line in
> the end of the `_qt_internal_qml_type_registration` function:
> 
> ```
>    target_include_directories(${effective_target} PRIVATE
>          $<TARGET_PROPERTY:${QT_CMAKE_EXPORT_NAMESPACE}::QmlPrivate,INTERFACE_INCLUDE_DIRECTORIES>
>     )
> ```
> 
> -Brad


Hi,

Please see the comments at https://bugreports.qt.io/browse/QTBUG-87776

The problem is that the Qml target expects the private headers of QmlPrivate to exist, because both Qml and QmlPrivate are exported as part of the Qt6Qml package.
That's usually the case with a from-source build of Qt.
In this case the installed private headers are split into a separate dev package, which I suppose is not installed, and due to the new diagnostic provided by latest CMake, configuration fails.

I don't think CMake provides a $<PATH_EXISTS:> genex, so we could wrap those references into an existence check.

I'm not sure there is any quick fix aside from making the qtdeclarative dev package a requirement.

Alexandru.

Message #47 received at 1087385@bugs.debian.org (full text, mbox, reply):

From: Sune Stolborg Vuorela <sune@vuorela.dk>

To: 1087385@bugs.debian.org, Brad King <brad.king@kitware.com>

Cc: Adrian Bunk <bunk@debian.org>, Hefee <hefee@debian.org>

Subject: Re: Bug#1087385: cmake 3.31.0-1 breaks Qt6Qml builds

Date: Thu, 14 Nov 2024 13:14:40 +0100

On Wednesday, November 13, 2024 9:23:14 PM CET Brad King wrote:

> The change in behavior is due to CMake 3.31 fixing this bug:
> 
> * https://gitlab.kitware.com/cmake/cmake/-/issues/25728

I suggest we upload a cmake with that fix reverted as a short term solution 
while figuring out what to do with the rest of it

What does the cmake maintainers say?

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Message #52 received at 1087385@bugs.debian.org (full text, mbox, reply):

From: Brad King <brad.king@kitware.com>

To: 1087385@bugs.debian.org

Cc: Adrian Bunk <bunk@debian.org>, Hefee <hefee@debian.org>, Sune Stolborg Vuorela <sune@vuorela.dk>

Subject: Re: Bug#1087385: cmake 3.31.0-1 breaks Qt6Qml builds

Date: Thu, 14 Nov 2024 10:21:38 -0500

On Thu, Nov 14, 2024 at 7:14 AM Sune Stolborg Vuorela wrote:
> > * https://gitlab.kitware.com/cmake/cmake/-/issues/25728
> I suggest we upload a cmake with that fix reverted as a short term solution
> while figuring out what to do with the rest of it
> What does the cmake maintainers say?

I'd rather not have Debian package a CMake that claims to be 3.31.0
but doesn't have the bug fixed.  Also, the diagnostic that has now been
exposed is correct.  Suppressing it just covers the symptom.

It seems that `qt6-declarative-dev`'s `Qt6QmlTargets.cmake` has
a dependency on content of `qt6-declarative-private-dev`, so why
not express that dependency in the `qt6-declarative-dev` package?

-Brad

Message #57 received at 1087385@bugs.debian.org (full text, mbox, reply):

From: Timo Röhling <roehling@debian.org>

To: Brad King <brad.king@kitware.com>, 1087385@bugs.debian.org

Cc: Adrian Bunk <bunk@debian.org>, Hefee <hefee@debian.org>, Sune Stolborg Vuorela <sune@vuorela.dk>

Subject: Re: [Pkg-cmake-team] Bug#1087385: cmake 3.31.0-1 breaks Qt6Qml builds

Date: Fri, 15 Nov 2024 09:03:35 +0100

[Message part 1 (text/plain, inline)]

Control: reassign -1 qt6-declarative-dev
Control: retitle -1 qt6-declarative-dev depends on qt6-declarative-private-dev

* Brad King <brad.king@kitware.com> [2024-11-14 10:21]:
>On Thu, Nov 14, 2024 at 7:14 AM Sune Stolborg Vuorela wrote:
>> > * https://gitlab.kitware.com/cmake/cmake/-/issues/25728
>> I suggest we upload a cmake with that fix reverted as a short term solution 
>> while figuring out what to do with the rest of it 
>> What does the cmake maintainers say?
>It seems that `qt6-declarative-dev`'s `Qt6QmlTargets.cmake` has 
>a dependency on content of `qt6-declarative-private-dev`, so why 
>not express that dependency in the `qt6-declarative-dev` package?
I think this is the best short term solution, as it accurately 
reflects the current state of affairs. I understand the Qt/KDE 
Maintainers' desire to keep the private API separate (and I agree 
with the notion), but the onus is on them to make it work, not on 
CMake to retain loopholes.

Besides, this keeps the issue contained within a single source 
package, so it is easy to drop the workaround as soon as the 
underlying problem has been solved, without the need to involve the 
CMake maintainers and possibly the Release Team in case the fix will 
be delayed beyond the toolchain freeze for trixie.

Cheers
Timo


-- 
⢀⣴⠾⠻⢶⣦⠀   ╭────────────────────────────────────────────────────╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling                                       │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯

[signature.asc (application/pgp-signature, inline)]

Message #68 received at 1087385@bugs.debian.org (full text, mbox, reply):

From: Sune Stolborg Vuorela <sune@vuorela.dk>

To: Brad King <brad.king@kitware.com>, 1087385@bugs.debian.org, Adrian Bunk <bunk@debian.org>, Hefee <hefee@debian.org>, Sune Stolborg Vuorela <sune@vuorela.dk>

Subject: Re: [Pkg-cmake-team] Bug#1087385: cmake 3.31.0-1 breaks Qt6Qml builds

Date: Fri, 15 Nov 2024 09:11:39 +0100

On Friday, November 15, 2024 9:03:35 AM CET Timo Röhling wrote:
> >It seems that `qt6-declarative-dev`'s `Qt6QmlTargets.cmake` has
> >a dependency on content of `qt6-declarative-private-dev`, so why
> >not express that dependency in the `qt6-declarative-dev` package?

Qt6QmlTargets.cmake creates two targets. One that you are likely to use and 
one you are very very very unlikely to need. Also using that very unlikely to 
need target also gives more work for the rest of Debian down the line.

> I think this is the best short term solution, as it accurately
> reflects the current state of affairs. I understand the Qt/KDE
> Maintainers' desire to keep the private API separate (and I agree
> with the notion), but the onus is on them to make it work, not on
> CMake to retain loopholes.
> 
> Besides, this keeps the issue contained within a single source
> package, so it is easy to drop the workaround as soon as the
> underlying problem has been solved, without the need to involve the
> CMake maintainers and possibly the Release Team in case the fix will
> be delayed beyond the toolchain freeze for trixie.

I think it is going to affect all of Qt6-packages, not just Qt6Declarative. At 
least from a quick glance over other of my Qt6*Targets.cmake with private dev 
things have the same thing.

It is just likely that Qt6Declarative is hit first in finding order.

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank

Message #73 received at 1087385@bugs.debian.org (full text, mbox, reply):

From: Brad King <brad.king@kitware.com>

To: 1087385@bugs.debian.org

Cc: Adrian Bunk <bunk@debian.org>, Hefee <hefee@debian.org>, Sune Stolborg Vuorela <sune@vuorela.dk>

Subject: Re: [Pkg-cmake-team] Bug#1087385: cmake 3.31.0-1 breaks Qt6Qml builds

Date: Fri, 15 Nov 2024 08:42:16 -0500

On Fri, Nov 15, 2024 at 3:11 AM Sune Stolborg Vuorela wrote:
> I think it is going to affect all of Qt6-packages, not just Qt6Declarative. At
> least from a quick glance over other of my Qt6*Targets.cmake with private dev
> things have the same thing.

This is not a new diagnostic.  Most of the other packages will
have already triggered it if they had the problem.  What makes
Qt6Qml special is the extra `target_include_directories` call
in `_qt_internal_qml_type_registration` I quoted previously.
That covered the diagnostic due to the now-fixed bug in CMake.

Either way, this is a problem that eventually needs to be worked
out in the Qt6 packaging regardless.

> Qt6QmlTargets.cmake creates two targets. One that you are likely to use and
> one you are very very very unlikely to need. Also using that very unlikely to
> need target also gives more work for the rest of Debian down the line.

Perhaps `Qt6QmlTargets` should be split by upstream to move the unlikely
target into a dedicated `Qt6QmlPrivateTargets` file.  Meanwhile, here is
a workaround one could apply in Debian packaging:

One could patch `Qt6QmlConfig.cmake` to, after loading `Qt6QmlTargets.cmake`,
modify the `Qt6::QmlPrivate` target's `INTERFACE_INCLUDE_DIRECTORIES`
property to remove the entries corresponding to `qt6-declarative-private-dev`
if those directories do not exist.  That will hide the dependency from the
CMake diagnostic.  If an application really needs the headers, the error will
occur during its compilation instead.

-Brad

Message #88 received at 1087385@bugs.debian.org (full text, mbox, reply):

From: Patrick Franz <deltaone@debian.org>

To: 1087385@bugs.debian.org, Brad King <brad.king@kitware.com>, Hefee <hefee@debian.org>, Sune Stolborg Vuorela <sune@debian.org>, Adrian Bunk <bunk@debian.org>, Timo Röhling <roehling@debian.org>

Subject: Re: [Pkg-cmake-team] Bug#1087385: cmake 3.31.0-1 breaks Qt6Qml builds

Date: Wed, 20 Nov 2024 00:00:19 +0100

Hi Brad,

On Fri, 15 Nov 2024 08:42:16 -0500 Brad King <brad.king@kitware.com> 
wrote:
[...]
> Perhaps `Qt6QmlTargets` should be split by upstream to move the 
> unlikely target into a dedicated `Qt6QmlPrivateTargets` file.  
> Meanwhile, here is a workaround one could apply in Debian packaging:
> 
> One could patch `Qt6QmlConfig.cmake` to, after loading 
> `Qt6QmlTargets.cmake`, modify the `Qt6::QmlPrivate` target's 
> `INTERFACE_INCLUDE_DIRECTORIES` property to remove the entries 
> corresponding to `qt6-declarative-private-dev` if those directories do 
> not exist.  That will hide the dependency from the CMake diagnostic.  
> If an application really needs the headers, the error will occur 
> during its compilation instead.

Thank you for that suggestion. I tried it, but unfortunately it only 
solves half the problem. While we're not looking for 
"/usr/include/x86_64-linux-gnu/qt6/QtQml/6.7.2" any more, Qt::QmlPrivate 
is linked against Qt::CorePrivate which means we need the private 
headers for qt6-base found in qt6-base-private-dev. That package would 
then need to be added manually to the build dependencies.
We could of course do a similar thing and check for 
"/usr/include/x86_64-linux-gnu/qt6/QtCore/6.7.2" and not link against 
Qt::CorePrivate if those directories do not exist. But it feels like a 
super-ugly hack and I cannot shake the feeling that I'll be going down 
the rabbit hole here (not your fault of course).
What is complicating matters is that both Qt6QmlConfig.cmake and 
Qt6QmlTargets.cmake do not exist explicitly in the qtdeclarative source, 
but are instead generated files from a template in qtbase. So any change 
there would affect every single Qt package and I honestly cannot judge 
the effect of such a change.

Sadly, it seems that we can only choose the lesser evil here and have to 
depend on the private-dev package(s) for the time being until Qt 
upstream comes up with a better solution unless anyone has a better 
idea.


-- 
Med vänliga hälsningar

Patrick Franz

Send a report that this bug log contains spam.