Both approaches fail — redox-toolchain.cmake overrides include paths.
Root cause: Qt6 cmake configs from qtdeclarative (built with qml_jit=OFF)
do not export Qt6Qml/Qt6Quick include directories properly for downstream
consumers. Headers exist at /usr/include/QtQml/QQmlEngine but cmake does
not add -I paths. This is the precise QML gate mechanism.
Qt6Core5Compat built (kwin dep). Kirigami still fails — QQmlEngine/QQuickItem
headers exist in sysroot but cmake find_package(Qt6Qml) include paths
are not being set. This is the exact QML gate: cmake integration needed
between qtdeclarative build output and downstream recipes.
Build evidence:
- qt5compat: built (libQt6Core5Compat now available)
- kglobalacceld: built
- kirigami: fails at C++ include stage (cmake finds Qt6Qml but
-I/usr/include/QtQml not in compile flags)
- kwin: fails at Qt6Gui Wayland plugin cmake target issue
Phase 4 KDE Plasma preparation:
kded6: new recipe at local/recipes/kde/kf6-kded6/ building the KDE
daemon from source. Depends on kf6-kconfig, kf6-kcoreaddons,
kf6-kcrash, kf6-kdbusaddons, kf6-kservice — all already built.
Added to redbear-full.toml package list. D-Bus activation file
already existed; removed TODO now that recipe exists.
kirigami: rewrite from stub to real CMake build. qtdeclarative
(Qt6Quick) is now available, so the real Kirigami can be built
instead of installing dummy cmake configs and a static lib placeholder.
Added qtshadertools and qtsvg as additional dependencies.
vasilito