Hi Brad, On Fri, 15 Nov 2024 08:42:16 -0500 Brad King <brad.k...@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
