Re: Does recipe specific sysrooot (or whatelse in current oe) break native dependencies?

[Patrick Ohly <patrick.ohly@intel.com>]

On Sun, 2017-02-19 at 14:26 -0800, Richard Purdie wrote:
> On Tue, 2017-02-14 at 11:26 +0100, Patrick Ohly wrote:
> > My testing was flawed: in addition to the RDEPENDS there also was a
> > DEPENDS with the same entry, and despite what was said earlier about
> > build dependencies, that entry did have an effect. So it is a bit
> > more
> > complicated.
> > 
> > The way I'd expect this to work for native tools is this:
> >      1. DEPENDS should be ignored (build dependencies like compiler
> >         which are not needed when using the resulting tool)
> 
> Firstly. this is not true at all. Native recipes have build
> dependencies just the same as target recipes.

Yes, of course. But here I was talking about installing an already built
tool in the RSS, and in that case the build dependencies are not always
necessary anymore.

What I hadn't considered is that there's no packaging and thus also no
analysis of ELF files to detect library dependencies. Without that, one
has no choice and must install all DEPENDS, even those that only provide
build tools that aren't needed anymore.

I'm not suggesting to add such packaging. It's another big change and it
is not clear whether the reduced size of the resulting sysroots really
would outweigh the extra costs and complexity (for example,
boot-strapping the ELF analysis).

> By comparison RDEPENDS of a native recipe are only needed after its
> been compiled and we're about to run it (at least by definition).

Let's focus on RDEPENDS.

> With a little more digging, I realised that base.bbclass does:
> 
> do_prepare_recipe_sysroot[deptask] = "do_populate_sysroot"
> 
> Note that this is "deptask", not "rdeptask".
> 
> The lack of the "r" means it will work off DEPENDS, not RDEPENDS.

So just to be clear, all RDEPENDS* variables are currently ignored when
populating the RSS. I think that's what surprised me. Some sort of
support for it also in the native case would make sense, because it is
cleaner and avoids rebuilding tools when only they runtime dependencies
change.

We just need to agree on something and then make it work. I propose we
use RDEPENDS_$i for i in PACKAGES, because unsetting PACKAGES in
native.bbclass when used via BBCLASSEXTEND is a hack that already fails
in some cases (like the PACKAGES_prepend that I mentioned earlier) and
because it is more consistent with target recipes.

To handle that case that a RDEPENDS_foobar pulls in a dependency that is
irrelevant because the foobar package would have been empty and skipped
if packaging was done, PACKAGES_class-native can be used to set a
smaller list. What about RDEPENDS for native-sdk? Does it matter there?

Can do_prepare_recipe_sysroot be extended to consider both DEPENDS and
RDEPENDS_$i?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.