[OE-core] Does recipe specific sysrooot (or whatelse in current oe) break native dependencies?

[Andreas Müller]

On Mon, Feb 13, 2017 at 1:26 AM, Andreas Müller
<schnitzeltony at googlemail.com> wrote:
> Hi
>
> I try to get meta-qt5-extra fit for latest oe-core (RSS). One thing
> that causes my attention is that many recipes's configure can be fixed
> by adding gettext-native. This seems odd to me because all of these
> recipes depend upon kdoctools which depends on gettext-native.
> For instance for kconfigwidgets depending on kdoctools:
>
> * in kdoctool'sworkdir/recipe-sysroot-native/usr/bin there is a gettext binary
> * but in kconfigwidgets'sworkdir/recipe-sysroot-native/usr/bin there
> isn't a gettext binary
>
> Is it possible that recipe specific sysroot broke native dependency chain?
>
> One note which might be important for this issue: In meta-qt5-extra I
> chose a the following design decision: If there is a pair of
> native/cross recipes
> * each cross recipe depends on native recipe
> * all other recipes depend on cross recipes
>
> This reduced maintenance efforts (I don't have to care if a recipe
> depends on cross libs or native executables) and avoids race trouble
> with cmake's toolchain path sequence 1. cross 2. native
>
> So what goes wrong here - or where am I mistaken?
>
Another more common examples:

* in meta-qt5-extra I could fix many recipes by depending on
qtbase-native although they already depended on qtbase (qtbase depends
on qtbase-native)
* right after recipe specific sysroot a dependency on qtbase-native
was added in cmake_qt5.bbclass although it depended on qtbase already
and qtbase depends on qtbase-native

Before we carry on adding dozens of dependencies and blacklisting
world: Are missing native dependencies a bug or a feature - or where
am I going wrong? What scares me most is that my way of depending
always on cross recipes in meta-qt5-extra will not work anymore
(mentioned in my previous mail) and turn into a unmaintainable burden.

Andreas