<div dir="ltr">Hi Andreas,<div><br></div><div>I think it's feature which was already there, but almost never triggered (even in test-dependencies.sh tests), but with RSS it fails reliably.</div><div><br></div><div>See:</div><div><a href="http://lists.openembedded.org/pipermail/openembedded-core/2016-July/124435.html">http://lists.openembedded.org/pipermail/openembedded-core/2016-July/124435.html</a><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 13, 2017 at 2:47 PM, Andreas Müller <span dir="ltr"><<a href="mailto:schnitzeltony@googlemail.com" target="_blank">schnitzeltony@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Feb 13, 2017 at 1:26 AM, Andreas Müller<br>
<<a href="mailto:schnitzeltony@googlemail.com">schnitzeltony@googlemail.com</a>> wrote:<br>
> Hi<br>
><br>
> I try to get meta-qt5-extra fit for latest oe-core (RSS). One thing<br>
> that causes my attention is that many recipes's configure can be fixed<br>
> by adding gettext-native. This seems odd to me because all of these<br>
> recipes depend upon kdoctools which depends on gettext-native.<br>
> For instance for kconfigwidgets depending on kdoctools:<br>
><br>
> * in kdoctool'sworkdir/recipe-<wbr>sysroot-native/usr/bin there is a gettext binary<br>
> * but in kconfigwidgets'sworkdir/<wbr>recipe-sysroot-native/usr/bin there<br>
> isn't a gettext binary<br>
><br>
> Is it possible that recipe specific sysroot broke native dependency chain?<br>
><br>
> One note which might be important for this issue: In meta-qt5-extra I<br>
> chose a the following design decision: If there is a pair of<br>
> native/cross recipes<br>
> * each cross recipe depends on native recipe<br>
> * all other recipes depend on cross recipes<br>
><br>
> This reduced maintenance efforts (I don't have to care if a recipe<br>
> depends on cross libs or native executables) and avoids race trouble<br>
> with cmake's toolchain path sequence 1. cross 2. native<br>
><br>
> So what goes wrong here - or where am I mistaken?<br>
><br>
</span>Another more common examples:<br>
<br>
* in meta-qt5-extra I could fix many recipes by depending on<br>
qtbase-native although they already depended on qtbase (qtbase depends<br>
on qtbase-native)<br>
* right after recipe specific sysroot a dependency on qtbase-native<br>
was added in cmake_qt5.bbclass although it depended on qtbase already<br>
and qtbase depends on qtbase-native<br>
<br>
Before we carry on adding dozens of dependencies and blacklisting<br>
world: Are missing native dependencies a bug or a feature - or where<br>
am I going wrong? What scares me most is that my way of depending<br>
always on cross recipes in meta-qt5-extra will not work anymore<br>
(mentioned in my previous mail) and turn into a unmaintainable burden.<br>
<div class="HOEnZb"><div class="h5"><br>
Andreas<br>
--<br>
______________________________<wbr>_________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org">Openembedded-core@lists.<wbr>openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/<wbr>mailman/listinfo/openembedded-<wbr>core</a><br>
</div></div></blockquote></div><br></div>