native.bbclass: populate native recipe with it's files
PATCH 1/1 native.bbclass: populate native recipe with it's files
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.
--- meta/classes/native.bbclass | 5 +++++ 1 file changed, 5 insertions(+)
meta/classes/native.bbclass +5 -0
@@ -174,6 +174,11 @@ python native_virtclass_handler () { addhandler native_virtclass_handler native_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise" +python do_addto_recipe_sysroot () { + bb.build.exec_func("extend_recipe_sysroot", d) +} +addtask addto_recipe_sysroot after do_populate_sysroot before do_build + inherit nopackages do_packagedata[stamp-extra-info] = ""
Signature · 1 line
2.7.4
Quoted 26 lines · Saul Wold
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.
Signed-off-by Saul Wold <[email protected]>---
meta/classes/native.bbclass | 5 +++++1 file changed, 5 insertions(+)meta/classes/native.bbclass +0
-0@@ -174,6 +174,11 @@ python native_virtclass_handler () {addhandler
native_virtclass_handlernative_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"meta/classes/native.bbclass +4
-0+python do_addto_recipe_sysroot () { + bb.build.exec_func("extend_recipe_sysroot", d) +} +addtask addto_recipe_sysroot after do_populate_sysroot before
Quoted 3 lines
do_build
+
inherit nopackages
I'm fine with adding this task as a shortcut to allow the particular recipe to be run from a recipe sysroot. What I don't want is every recipe needing to run this all the time which the "before do_build" enables. Can we do this without the do_build piece and manually run the task where needed?
Cheers,
Richard
Quoted 16 lines · Saul Wold
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.
Signed-off-by Saul Wold <[email protected]>--- meta/classes/native.bbclass | 5 +++++ 1 file changed, 5 insertions(+)meta/classes/native.bbclass +0
-0
meta/classes/native.bbclass python native_virtclass_handler () { · line 180
Quoted 7 lines
meta/classes/native.bbclass +4
-0@@ -174,6 +174,11 @@ python native_virtclass_handler () { addhandler native_virtclass_handler native_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise" +python do_addto_recipe_sysroot () { + bb.build.exec_func("extend_recipe_sysroot", d) +} +addtask addto_recipe_sysroot after do_populate_sysroot before do_build
I think this is digging a hole that everyone will use as a short cut.
Quoted 5 lines
meta/classes/native.bbclass +1
-0+ inherit nopackages do_packagedata[stamp-extra-info] = ""
Quoted 5 lines · Saul Wold
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?)
Signature · 6 lines
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.
Quoted 14 lines · Patrick Ohly
Quoted 8 lines · Saul Wold
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 (?).
Quoted 7 lines
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...
Cheers,
Richard
Quoted 19 lines · Richard Purdie
Quoted 18 lines · Patrick Ohly
Quoted 8 lines · Saul Wold
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}"
Quoted 7 lines
Quoted 3 lines
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_workmight 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...
Signature · 6 lines
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.