All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] native.bbclass: populate native recipe with it's files
@ 2017-02-16 23:46 Saul Wold
  2017-02-16 23:53 ` Richard Purdie
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Saul Wold @ 2017-02-16 23:46 UTC (permalink / raw)
  To: openembedded-core, richard.purdie

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 <sgw@linux.intel.com>
---
 meta/classes/native.bbclass | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index ec91fc3..d9dfea7 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -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] = ""
-- 
2.7.4



^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] native.bbclass: populate native recipe with it's files
  2017-02-16 23:46 [PATCH] native.bbclass: populate native recipe with it's files Saul Wold
@ 2017-02-16 23:53 ` Richard Purdie
  2017-02-17  0:15 ` Khem Raj
  2017-02-17  7:25 ` Patrick Ohly
  2 siblings, 0 replies; 7+ messages in thread
From: Richard Purdie @ 2017-02-16 23:53 UTC (permalink / raw)
  To: Saul Wold, openembedded-core

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.
> 
> Signed-off-by: Saul Wold <sgw@linux.intel.com>
> ---
>  meta/classes/native.bbclass | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/meta/classes/native.bbclass
> b/meta/classes/native.bbclass
> index ec91fc3..d9dfea7 100644
> --- a/meta/classes/native.bbclass
> +++ b/meta/classes/native.bbclass
> @@ -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

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] native.bbclass: populate native recipe with it's files
  2017-02-16 23:46 [PATCH] native.bbclass: populate native recipe with it's files Saul Wold
  2017-02-16 23:53 ` Richard Purdie
@ 2017-02-17  0:15 ` Khem Raj
  2017-02-17  7:25 ` Patrick Ohly
  2 siblings, 0 replies; 7+ messages in thread
From: Khem Raj @ 2017-02-17  0:15 UTC (permalink / raw)
  To: openembedded-core



On 2/16/17 3:46 PM, 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.
> 
> Signed-off-by: Saul Wold <sgw@linux.intel.com>
> ---
>  meta/classes/native.bbclass | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
> index ec91fc3..d9dfea7 100644
> --- a/meta/classes/native.bbclass
> +++ b/meta/classes/native.bbclass
> @@ -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.

> +
>  inherit nopackages
>  
>  do_packagedata[stamp-extra-info] = ""
> 


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] native.bbclass: populate native recipe with it's files
  2017-02-16 23:46 [PATCH] native.bbclass: populate native recipe with it's files Saul Wold
  2017-02-16 23:53 ` Richard Purdie
  2017-02-17  0:15 ` Khem Raj
@ 2017-02-17  7:25 ` Patrick Ohly
  2017-02-19 18:47   ` Richard Purdie
  2 siblings, 1 reply; 7+ messages in thread
From: Patrick Ohly @ 2017-02-17  7:25 UTC (permalink / raw)
  To: Saul Wold; +Cc: openembedded-core

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?)

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] native.bbclass: populate native recipe with it's files
  2017-02-17  7:25 ` Patrick Ohly
@ 2017-02-19 18:47   ` Richard Purdie
  2017-02-20 12:36     ` Patrick Ohly
  0 siblings, 1 reply; 7+ messages in thread
From: Richard Purdie @ 2017-02-19 18:47 UTC (permalink / raw)
  To: Patrick Ohly, Saul Wold; +Cc: openembedded-core

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

Cheers,

Richard


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] native.bbclass: populate native recipe with it's files
  2017-02-19 18:47   ` Richard Purdie
@ 2017-02-20 12:36     ` Patrick Ohly
  0 siblings, 0 replies; 7+ messages in thread
From: Patrick Ohly @ 2017-02-20 12:36 UTC (permalink / raw)
  To: Richard Purdie; +Cc: openembedded-core

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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* [PATCH] native.bbclass: populate native recipe with it's files
@ 2017-02-20  5:40 Saul Wold
  0 siblings, 0 replies; 7+ messages in thread
From: Saul Wold @ 2017-02-20  5:40 UTC (permalink / raw)
  To: openembedded-core, richard.purdie

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 <sgw@linux.intel.com>
---
V2 - Removes "before do_build" so not force the change

 meta/classes/native.bbclass | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index ec91fc3..d9dfea7 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -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
+
 inherit nopackages
 
 do_packagedata[stamp-extra-info] = ""
-- 
2.7.4



^ permalink raw reply related	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2017-02-20 12:36 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-16 23:46 [PATCH] native.bbclass: populate native recipe with it's files Saul Wold
2017-02-16 23:53 ` Richard Purdie
2017-02-17  0:15 ` Khem Raj
2017-02-17  7:25 ` Patrick Ohly
2017-02-19 18:47   ` Richard Purdie
2017-02-20 12:36     ` Patrick Ohly
2017-02-20  5:40 Saul Wold

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.