Issues cross-compiling Qt6 for embedded linux distribution

I understand this is not the format of a bug report developers appreciate, but I think context / the big picture is important to be able to classify the issues I'm experiencing, e.g. as documentation issues, understanding issues or actual factual bugs.

Happy to create atomic / singular bug reports, once there has been some assessment on whether it's a bug or misunderstanding or whatever.

So here's my journey trying to cross-compile Qt6 with the idea to port and package Qt6 for the embedded linux distribution OpenWrt, as I already did for Qt4 and Qt5 in the past.

For Qt4 and Qt5 I used the qmake build system, which for Qt6 isn't available anymore.

As I understand, one of the main incentives for the switch from qmake to cmake is a clear separation between host and target builds - which I appreciate, given that it's lack and mangling really gave me quite some headaches with previous versions using qmake.

However I'm now running into quite a few issues with Qt6 and cmake as well:

First, I'm building qt6base for host the - which appears to work fine.
Install prefix for the host build is "$PREFIX_HOST/" (mind: no "/usr/ or "/usr/local/" or alike), hence it installs mkspecs into $PREFIX_HOST/mkspecs.

My host builds don't get passed anything special (except "$PREFIX_HOST/" as INSTALL_PREFIX), so they default to the linux-g++ mkspec.

For Qt5 I've used a custom mkspec for cross-compiling / building for the target ("linux-openwrt-g++"), which I figured I might take over also for Qt6 to still support building qmake based projects, even though, yes, qmake is not used anymore for building qt6base.

So my target builds get passed the following flags via cmake: 

-DQT_HOST_PATH="$PREFIX_HOST" -DQT_MKSPECS_DIR="$PREFIX_HOST/mkspecs" -DQT_QMAKE_TARGET_MKSPEC="linux-openwrt-g++"

However, building qt6base for the target fails if my specified (custom) mkspec is not available - bailing out with "Unknown platform".

Question 1: Why is building qt6base for the target failing, if specified mkspec is not found, even though qt6base claims to not use qmake/mkspecs anymore for being built?

Anyway, whatever, if it needs the mkspec I'm happy to provide it: just copy my custom mkspec into $PREFIX_HOST/mkspecs/, where the qt6base host build installed all its mkspecs.

However building qt6base for the target still fails with not finding my custom mkspec.

Turns out: qt6base build process for the target is not searching $PREFIX_HOST/mkspecs/, but (only) ./mkspecs/, meaning the mkspecs-directory inside the build-directory (e.g. /src/qtbase-everywhere-src-6.9.0/mkspecs/). 

Question 2: Why is building qt6base for the target not searching for mkspecs files in $PREFIX_HOST/mkspecs/ but (only) inside ./mkspecs/? Maybe that is a special case for qtbase?

Anyway, that's easy to workaround as well, right? As the qt6base build process for the target is not supposed to use any of the specified mkspec info anyway (but for some reason still requires them to be present, see question 1), let's just pass / default to "linux-g+" for the target build as "dummy". Which works, however that specified mkspec (linux-g+) info appears to now be saved somewhere, being picked up when building 3rd party software using qmake. So, works for the qt6base target build, but nothing after that. So, let's skip that approach for now.

Option 2 then: let's just copy our custom mkspec into the src-directory (/src/qtbase-everywhere-src-6.9.0/mkspecs/) - feels unnecessarily redundant, but whatever serve the purpose.

Building qt6base for the target successful - great!

Now let's build the next package: qt6declarative. That requires Qt6QmlTools (as host tools) - so building qt6declarative for the host first. All of it. Although just some host tools are needed.

Question 3: Is there a way to trigger minimal / host-only builds, so we only build just enough in order to meet the requirements for the target build?

Anyway, not a big deal, CPU and storage shouldn't be a deal breakers anymore these days, right? Let's just work with full host builds, at least for now.

Attempting to build qt6declarative for the target now (with above mentioned target flags passed to cmake), getting flooded with messages alike:

CMake Error in src/qmltoolingsettings/CMakeLists.txt:
  Imported target "Qt6::Core" includes non-existent path
    "$STAGING_DIR/usr/mkspecs/linux-openwrt-g++

Ok, my specified custom mkspec (linux-openwrt-g++) is being searched for and not found. But why in this directory? Why is it looking for mkspecs underneath my staging-directory and not $PREFIX_HOST/mkspecs/?
For clarification: $STAGING_DIR is my staging-directory, what I believe is called "sysroot" in other cross-compiling contexts, meant to hold all the binaries and info built for target.

I would have expected the build process for the target trying to search for mkspecs in $PREFIX_HOST/mkspecs/. As a matter of fact, that's the only place mkspecs are located in this setup.
Host builds install their files in $PREFIX_HOST/, target builds install their files in $STAGING_DIR/. And, making fully sense to me, no mkspecs got installed into the $STAGING_DIR/ during the qt6base build.

Question 4: why is building qt6declarative for the target searching for my specified custom mkspec in $STAGING_DIR/usr/mkspecs/ instaed of $PREFIX_HOST/mkspecs/?

What's also noticable: the "/usr/"-prefix. The only way I can come up with where $STAGING_DIR/usr is coming from, is, that's the prefix passed to the qt6base target build.

That's where I'm currently stuck.