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

[Alexandru Croitor]

On Wed, 13 Nov 2024 15:23:14 -0500 Brad King <brad.king at 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.