qt: dual-stage plugins to <stage>/plugins (qtwayland/qtsvg/qtdeclarative)

Qt cmake plugin targets resolve each plugin .so via <sysroot>/plugins (the
_IMPORT_PREFIX is computed from the cmake files under <sysroot>/lib/cmake, i.e.
the sysroot root, not <sysroot>/usr), but cmake --install --prefix .../usr puts
plugins at usr/plugins. qtbase already works around this by staging plugins to
BOTH usr/plugins and plugins (recipe.toml ~L739); qtwayland/qtsvg/qtdeclarative
did not, so their plugins (wayland decorations, svg imageformats/iconengines,
qmltooling) were unreachable at <sysroot>/plugins and any Qt6Gui/Qt6Qml consumer
failed: imported target references "<sysroot>/plugins/.../foo.so" but this file
does not exist. This blocked kf6-kwindowsystem (sddm dep) on the Adwaita
decoration plugin. Add a shared redbear_qt_dual_stage_plugins helper and call it
after install in all three. (Note qml already resolves via the qml symlink since
qtbase does not dual-stage qml, so <sysroot>/qml is a symlink not a real dir.)

local/recipes/qt/qtdeclarative/recipe.toml

@@ -268,6 +268,10 @@ cmake --build . -j${COOKBOOK_MAKE_JOBS} 2>/dev/null || echo "Some targets failed
 # errors because qfeatures.h is not staged into the sysroot.
 cmake --install . --prefix "${COOKBOOK_STAGE}/usr"
 
+# Stage plugins to <stage>/plugins too so Qt cmake plugin targets (which look in
+# <sysroot>/plugins) can find qtdeclarative's qmltooling plugins.
+redbear_qt_dual_stage_plugins "${COOKBOOK_STAGE}"
+
 # Safety net: some Qt build configurations place qfeatures.h only in the
 # build tree, not under the install prefix. Explicitly copy it to the stage
 # and to every QtCore include directory in the sysroot to prevent

local/recipes/qt/qtsvg/recipe.toml

@@ -41,6 +41,10 @@ cmake --build . -j${COOKBOOK_MAKE_JOBS}
 
 cmake --install . --prefix "${COOKBOOK_STAGE}/usr"
 
+# Stage plugins to <stage>/plugins too so Qt cmake plugin targets (which look in
+# <sysroot>/plugins) can find qtsvg's imageformats/iconengines plugins.
+redbear_qt_dual_stage_plugins "${COOKBOOK_STAGE}"
+
 for lib in lib/libQt6*.so*; do
     [ -f "${lib}" ] && cp -an "${lib}" "${COOKBOOK_STAGE}/usr/lib/"
 done

local/recipes/qt/qtwayland/recipe.toml

@@ -113,6 +113,11 @@ cmake "${COOKBOOK_SOURCE}" \
 cmake --build . -j"${COOKBOOK_MAKE_JOBS}"
 cmake --install . --prefix "${COOKBOOK_STAGE}/usr"
 
+# Stage plugins to <stage>/plugins too (not just usr/plugins) so Qt's cmake
+# plugin targets, which resolve .so via <sysroot>/plugins, can find qtwayland's
+# decoration/shell/graphics-integration plugins. Mirrors qtbase's workaround.
+redbear_qt_dual_stage_plugins "${COOKBOOK_STAGE}"
+
 # Remove RPATH from all libraries
 find "${COOKBOOK_STAGE}" -name '*.so*' -exec patchelf --remove-rpath {} \\; 2>/dev/null || true
 """

local/scripts/lib/qt-sysroot.sh

@@ -24,6 +24,23 @@ redbear_qt_link_plugins_dir() {
     fi
 }
 
+# Qt's generated cmake plugin targets resolve each plugin .so via
+# <sysroot>/plugins (the _IMPORT_PREFIX is computed from the cmake files under
+# <sysroot>/lib/cmake, i.e. the sysroot root, NOT <sysroot>/usr). But
+# `cmake --install --prefix .../usr` puts plugins at usr/plugins. qtbase works
+# around this by staging plugins to BOTH usr/plugins and plugins; any Qt module
+# that ships plugins (qtwayland decorations, qtsvg imageformats, qtdeclarative
+# qmltooling, ...) must do the same or a consumer's find_package fails: imported
+# target references "<sysroot>/plugins/.../foo.so" but this file does not exist.
+# Call this after `cmake --install` with the stage root ($COOKBOOK_STAGE).
+redbear_qt_dual_stage_plugins() {
+    local stage="$1"
+    if [ -d "${stage}/usr/plugins" ]; then
+        mkdir -p "${stage}/plugins"
+        cp -a "${stage}/usr/plugins/." "${stage}/plugins/" 2>/dev/null || true
+    fi
+}
+
 redbear_qt_prepare_common_sysroot() {
     local sysroot="$1"
     redbear_qt_link_sysroot_dirs "$sysroot" plugins mkspecs metatypes modules qml