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. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core