Re: [PATCH] native.bbclass: populate native recipe with it's files

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

On Sun, 2017-02-19 at 10:47 -0800, Richard Purdie wrote:
> On Fri, 2017-02-17 at 08:25 +0100, Patrick Ohly wrote:
> > On Thu, 2017-02-16 at 15:46 -0800, Saul Wold wrote:
> > > 
> > > This allows a native package's recipe-sysroot-native to be
> > > populated with
> > > that packages native image files.  This in turns allows it to be
> > > used by
> > > scripts or other tools without creating un-necessary DEPENDS.
> > > 
> > > An example of this is systemtap-native and the crosstap script.
> > The intended usage wasn't clear to me at first. I think it is
> > something
> > like "bitbake foobar-native" and then calling foobar's tools directly
> > from tmp/work/*/foobar-native/*/recipe-sysroot-native (?).
> > 
> > If true, then any recipe intending to be used like that also needs to
> > exclude itself from do_rm_work:
> > RM_WORK_EXCLUDE += "${PN}"
> > 
> > Or perhaps more selectively exclude the RSS:
> > RM_WORK_EXCLUDE_ITEMS += "recipe-sysroot-native" (is there a variable
> > for this name?)
> 
> I've been idly wondering whether just excluding recipe-sysroot* from
> rm_work might be useful since its mostly hardlinked files anyway and
> likely doesn't cause too much of a space issue...

It might still be useful to remove even the hardlinks, to spread out the
IO required to clean up after a build - "rm -rf tmp" can take a long
time. But I haven't measured how much of a difference rm_work makes in
this case.

Regarding Saul's patch: I've used it together with devtool to build and
debug a native tool. After "devtool build foo-native" one cannot
actually run foo because it is not installed in a sysroot. "bitbake
foo-native:do_addto_recipe_sysroot" fixes that. I also enabled debug
information and prevented native sysroot stripping for this particular
use-case. I'll probably file an enhancement request for devtool about
this...

-- 
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.