On Mon, 2017-02-13 at 16:45 +0100, Andreas Müller wrote: > On Mon, Feb 13, 2017 at 4:24 PM, Patrick Ohly <patrick.o...@intel.com > > wrote: > > On Mon, 2017-02-13 at 15:36 +0100, Martin Jansa wrote: > > > 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. > > > > > > See: > > > http://lists.openembedded.org/pipermail/openembedded-core/2016-Ju > > > ly/124435.html > Richard wrote > > > > What it does mean is that any recipe needing a -native recipe to > > build > > should list it in DEPENDS directly, not rely on other dependencies > > to > > pull it in for them. This applies to pkgconfig-native, intltool- > > native > > and also to wayland-native. > This answers my question and leaves me unhappy - I am out for a > while..
To be clear, you can't depend on the build dependencies of some other recipe to be available to your recipe just because you DEPEND on it. The RDEPENDS issue that Patrick mentions is a different one, its a valid recipe markup problem we have processing RDEPENDS information in the native case. The kind of indirection that Andreas sounds like he's been relying on may have happened to work most of the time but I'd bet there were ways that a semi populated sstate cache could break it. With RSS, we encoded the sstate behaviour in a deterministic way so the races that might have happened now do happen all the time. The simple solution for repetitive dependencies and shortcuts is just to create a class, list all the things you need in there and then inherit the class in the recipes as appropriate. I'd hope that isn't too hard to sort out... Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
