Staging - time to end the current mess?

Staging - time to end the current mess?

[Richard Purdie]

At OEDEM two years ago I proposed radically altering the way staging
worked. For those that don't remember the bad old days, the staging
directory layout didn't match that of the target file system meaning
every recipe needed a custom do_stage and things were a mess.

We changed the layout allowing the use of the gcc/binutils sysroot
options and also started widespread use of autotools_stage_all and I'd
say things look much improved compared to how they were.

Anyone who has looked at the packaged-staging code will probably agree
there is still a way to go though - its horrendously complicated. We
also do a lot of duplication. I'd like to propose a new simple way of
doing things. We'd have the following work flow:


[...]
do_compile - up to here all as usual
do_install - Everything installs into a DESTDIR (including -native)
do_package - Takes a copy of the DESTDIR, applies any .la/.pc mangling
             then splits into packages as usual
do_populate_staging - Takes a copy of the DESTDIR, mangles, installs 
             into staging and creates staging packages from this

Firstly, does any disagree with this approach or can we all agree its a
nice objective?

Pros:

* Only one "make install"
* We can start to work out the differences between do_install and 
  do_stage and minimise them (there should be none bar .la mangling)
* Cleaner and simpler do_stage step
* Packaged-Staging becomes much simpler
* Builds should be faster as staging timestamp snapshots are not 
  required and staging lock taking should be minimal.

Cons:

* Very different to what we have now - how to get there?
* Likely to be some breakage in any transition

I really like the idea in principle, in practise its hard to get there
incrementally without breaking things. I'm trying to come up with some
code which does that and I'm hoping to have something for OEDEM.

For now I'd like to ask if there is agreement we need to do this and
support to make this happen?

Cheers,

Richard

Re: Staging - time to end the current mess?

[Henning Heinold]

On Mon, Nov 02, 2009 at 01:43:27PM +0000, Richard Purdie wrote:
> [...]
> do_compile - up to here all as usual
> do_install - Everything installs into a DESTDIR (including -native)
> do_package - Takes a copy of the DESTDIR, applies any .la/.pc mangling
>              then splits into packages as usual
> do_populate_staging - Takes a copy of the DESTDIR, mangles, installs 
>              into staging and creates staging packages from this
> 
> Firstly, does any disagree with this approach or can we all agree its a
> nice objective?

Yeah thats nice. I will help for instance with pkgconfig-class which now "sed's" the
.pc files in builddir before installing it.

Bye Henning

Re: Staging - time to end the current mess?

[Koen Kooi]

On 02-11-09 14:43, Richard Purdie wrote:
> At OEDEM two years ago I proposed radically altering the way staging
> worked. For those that don't remember the bad old days, the staging
> directory layout didn't match that of the target file system meaning
> every recipe needed a custom do_stage and things were a mess.
>
> We changed the layout allowing the use of the gcc/binutils sysroot
> options and also started widespread use of autotools_stage_all and I'd
> say things look much improved compared to how they were.
>
> Anyone who has looked at the packaged-staging code will probably agree
> there is still a way to go though - its horrendously complicated. We
> also do a lot of duplication. I'd like to propose a new simple way of
> doing things. We'd have the following work flow:
>
>
> [...]
> do_compile - up to here all as usual
> do_install - Everything installs into a DESTDIR (including -native)
> do_package - Takes a copy of the DESTDIR, applies any .la/.pc mangling
>               then splits into packages as usual
> do_populate_staging - Takes a copy of the DESTDIR, mangles, installs
>               into staging and creates staging packages from this
>
> Firstly, does any disagree with this approach or can we all agree its a
> nice objective?

Can we make the mangling a seperate tasks? I tend to do the mangling in 
do_compile_append to be able to do builds *on* the target as well.

> Pros:
>
> * Only one "make install"
> * We can start to work out the differences between do_install and
>    do_stage and minimise them (there should be none bar .la mangling)
> * Cleaner and simpler do_stage step
> * Packaged-Staging becomes much simpler
> * Builds should be faster as staging timestamp snapshots are not
>    required and staging lock taking should be minimal.
>
> Cons:
>
> * Very different to what we have now - how to get there?
> * Likely to be some breakage in any transition

And

* 'make install' doesn't actually work properly for lots of packages 
(you know, the ones with handcrafted makefiles)

But we can solve that by putting the custom do_stage() methods for those 
in do_install(), right?


> I really like the idea in principle, in practise its hard to get there
> incrementally without breaking things. I'm trying to come up with some
> code which does that and I'm hoping to have something for OEDEM.
>
> For now I'd like to ask if there is agreement we need to do this and
> support to make this happen?

You have my agreement.

regards,

Koen

Re: Staging - time to end the current mess?

[Richard Purdie]

On Mon, 2009-11-02 at 15:29 +0100, Koen Kooi wrote:
> On 02-11-09 14:43, Richard Purdie wrote:
> > At OEDEM two years ago I proposed radically altering the way staging
> > worked. For those that don't remember the bad old days, the staging
> > directory layout didn't match that of the target file system meaning
> > every recipe needed a custom do_stage and things were a mess.
> >
> > We changed the layout allowing the use of the gcc/binutils sysroot
> > options and also started widespread use of autotools_stage_all and I'd
> > say things look much improved compared to how they were.
> >
> > Anyone who has looked at the packaged-staging code will probably agree
> > there is still a way to go though - its horrendously complicated. We
> > also do a lot of duplication. I'd like to propose a new simple way of
> > doing things. We'd have the following work flow:
> >
> >
> > [...]
> > do_compile - up to here all as usual
> > do_install - Everything installs into a DESTDIR (including -native)
> > do_package - Takes a copy of the DESTDIR, applies any .la/.pc mangling
> >               then splits into packages as usual
> > do_populate_staging - Takes a copy of the DESTDIR, mangles, installs
> >               into staging and creates staging packages from this
> >
> > Firstly, does any disagree with this approach or can we all agree its a
> > nice objective?
> 
> Can we make the mangling a seperate tasks? I tend to do the mangling in 
> do_compile_append to be able to do builds *on* the target as well.

I just published my WIP tree:

http://cgit.openembedded.net/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress

and specifically:

http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?h=rpurdie/work-in-progress&id=1d69a38be629a70faf65dd9f2e9db12164071bfd

which means we'd start declaring "mangling" functions in their own
right. Does that work for you?

Where we run these is then up to the core metadata so we can attach them
to stage/install/compile as makes sense. I want to declare some
conventions of the directories these operate on so we can make the
functions "relocatable" by changing the input variables.

> And
> 
> * 'make install' doesn't actually work properly for lots of packages 
> (you know, the ones with handcrafted makefiles)
> 
> But we can solve that by putting the custom do_stage() methods for those 
> in do_install(), right?

Those packages will already have a custom do_install in some directory
so we can just use them as is.

Cheers,

Richard

Re: Staging - time to end the current mess?

[Koen Kooi]

On 02-11-09 16:00, Richard Purdie wrote:
> On Mon, 2009-11-02 at 15:29 +0100, Koen Kooi wrote:
>> On 02-11-09 14:43, Richard Purdie wrote:
>>> At OEDEM two years ago I proposed radically altering the way staging
>>> worked. For those that don't remember the bad old days, the staging
>>> directory layout didn't match that of the target file system meaning
>>> every recipe needed a custom do_stage and things were a mess.
>>>
>>> We changed the layout allowing the use of the gcc/binutils sysroot
>>> options and also started widespread use of autotools_stage_all and I'd
>>> say things look much improved compared to how they were.
>>>
>>> Anyone who has looked at the packaged-staging code will probably agree
>>> there is still a way to go though - its horrendously complicated. We
>>> also do a lot of duplication. I'd like to propose a new simple way of
>>> doing things. We'd have the following work flow:
>>>
>>>
>>> [...]
>>> do_compile - up to here all as usual
>>> do_install - Everything installs into a DESTDIR (including -native)
>>> do_package - Takes a copy of the DESTDIR, applies any .la/.pc mangling
>>>                then splits into packages as usual
>>> do_populate_staging - Takes a copy of the DESTDIR, mangles, installs
>>>                into staging and creates staging packages from this
>>>
>>> Firstly, does any disagree with this approach or can we all agree its a
>>> nice objective?
>>
>> Can we make the mangling a seperate tasks? I tend to do the mangling in
>> do_compile_append to be able to do builds *on* the target as well.
>
> I just published my WIP tree:
>
> http://cgit.openembedded.net/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress
>
> and specifically:
>
> http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?h=rpurdie/work-in-progress&id=1d69a38be629a70faf65dd9f2e9db12164071bfd
>
> which means we'd start declaring "mangling" functions in their own
> right. Does that work for you?

That was exactly what I was thinking about :)

> Where we run these is then up to the core metadata so we can attach them
> to stage/install/compile as makes sense. I want to declare some
> conventions of the directories these operate on so we can make the
> functions "relocatable" by changing the input variables.
>
>> And
>>
>> * 'make install' doesn't actually work properly for lots of packages
>> (you know, the ones with handcrafted makefiles)
>>
>> But we can solve that by putting the custom do_stage() methods for those
>> in do_install(), right?
>
> Those packages will already have a custom do_install in some directory
> so we can just use them as is.

My biggest fear is these kind of recipes:

do_install() {
	oe_libinstall foo ${D}
}

do_stage() }
	oe_libinstall foo ${D}
	cp foo.h ${STAGING_INC_DIR}
}

I guess we could grep for do_stage_{ap,pre}pend to find the worst 
offenders and gradually fix up remaining offenders.

regards,

Koen

Re: Staging - time to end the current mess?

[Richard Purdie]

On Mon, 2009-11-02 at 16:18 +0100, Koen Kooi wrote:
> My biggest fear is these kind of recipes:
> 
> do_install() {
> 	oe_libinstall foo ${D}
> }
> 
> do_stage() }
> 	oe_libinstall foo ${D}
> 	cp foo.h ${STAGING_INC_DIR}
> }
> 
> I guess we could grep for do_stage_{ap,pre}pend to find the worst 
> offenders and gradually fix up remaining offenders.

I'm hoping that with some clever magic, what I create will continue to
use these "legacy" staging functions when they're defined giving us a
transition path. As we go through the recipes fixing them up to use the
fastpath, we'll just have to catch those things. They are by definition
broken anyway so this is a good thing to do.

Cheers,

Richard

Re: Staging - time to end the current mess?

[Frans Meulenbroeks]

2009/11/2 Koen Kooi <k.kooi@student.utwente.nl>:
> On 02-11-09 14:43, Richard Purdie wrote:
>>
>> At OEDEM two years ago I proposed radically altering the way staging
>> worked. For those that don't remember the bad old days, the staging
>> directory layout didn't match that of the target file system meaning
>> every recipe needed a custom do_stage and things were a mess.
>>
>> We changed the layout allowing the use of the gcc/binutils sysroot
>> options and also started widespread use of autotools_stage_all and I'd
>> say things look much improved compared to how they were.
>>
>> Anyone who has looked at the packaged-staging code will probably agree
>> there is still a way to go though - its horrendously complicated. We
>> also do a lot of duplication. I'd like to propose a new simple way of
>> doing things. We'd have the following work flow:
>>
>>
>> [...]
>> do_compile - up to here all as usual
>> do_install - Everything installs into a DESTDIR (including -native)
>> do_package - Takes a copy of the DESTDIR, applies any .la/.pc mangling
>>              then splits into packages as usual
>> do_populate_staging - Takes a copy of the DESTDIR, mangles, installs
>>              into staging and creates staging packages from this
>>
>> Firstly, does any disagree with this approach or can we all agree its a
>> nice objective?
>
> Can we make the mangling a seperate tasks? I tend to do the mangling in
> do_compile_append to be able to do builds *on* the target as well.
>
>> Pros:
>>
>> * Only one "make install"
>> * We can start to work out the differences between do_install and
>>   do_stage and minimise them (there should be none bar .la mangling)
>> * Cleaner and simpler do_stage step
>> * Packaged-Staging becomes much simpler
>> * Builds should be faster as staging timestamp snapshots are not
>>   required and staging lock taking should be minimal.
>>
>> Cons:
>>
>> * Very different to what we have now - how to get there?
>> * Likely to be some breakage in any transition
>
> And
>
> * 'make install' doesn't actually work properly for lots of packages (you
> know, the ones with handcrafted makefiles)
>
> But we can solve that by putting the custom do_stage() methods for those in
> do_install(), right?

I'm in favour of the proposal.
If not breaking things is important maybe we can call the stage
differently and transfer packages from the old to the new.
Perhaps not too desirable as this gives a transition period that
probably never ends.

Wrt the packages were make install does not properly work:
I would expect for packages where it mostly matters (libs etc) the
install to be proper.

And if make install does not work properly the desired solution is
(imho) not to repair it in do_stage or do_install, but instead come up
with a patch for the Makefile (and preferably submit it to the package
to get it repaired more permanently.

Frans.

>
>
>> I really like the idea in principle, in practise its hard to get there
>> incrementally without breaking things. I'm trying to come up with some
>> code which does that and I'm hoping to have something for OEDEM.
>>
>> For now I'd like to ask if there is agreement we need to do this and
>> support to make this happen?
>
> You have my agreement.
>
> regards,
>
> Koen
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: Staging - time to end the current mess?

[Marcin Juszkiewicz]

Dnia poniedziałek, 2 listopada 2009 o 14:43:27 Richard Purdie napisał(a):
> For now I'd like to ask if there is agreement we need to do this and
> support to make this happen?

+1 from me

Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Staging - time to end the current mess - now with patches

[Richard Purdie]

This is much more interesting with patches so we now have:

http://cgit.openembedded.net/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress

I ended up cleaning a lot of stuff up as I went but the two really
interesting things this branch contains are:

a) Removal of the layout_* variables. This allows Poky's cross canadian
SDK functionality to be merged. It also cleans up things quite a bit,
I've not tested how the other canadian implementation fairs with this
but the intent is to replace that with the Poky implementation which is
much cleaner (no boatloads of duplicated variables and uses
BBCLASSEXTEND).

b) Change the way do_stage operates.

The intent is that do_install installs to ${D}. Nothing should operate
directly on ${D} other than the install.

do_package takes a copy of ${D} into ${PKGD} and then runs the functions
in PACKAGE_PREPROCESS_FUNCS which can alter this directory. The result
is then packaged.

do_stage detects if the do_stage function is defined. The default is
there is no definition anymore. If it is defined we go into legacy mode
which works like current staging, we take a lock, take a snapshot of
staging, run do_stage, run any SYSROOT_PREPROCESS_FUNCS which operate
against SYSROOT_DESTDIR="", see what changed, take a copy of the changes
and release the lock.

If we're not legacy, SYSROOT_DESTDIR=${WORKDIR}/sysroot-destdir, we copy
${D} into ${SYSROOT_DESTDIR}/${STAGING_DIR_TARGET}, we any
SYSROOT_PREPROCESS_FUNCS against SYSROOT_DESTDIR, save the result for
creating the staging package, take the staging lock and copy into
staging ("install the package"), release the lock.

For fun, we also detect two special cases - where autotools_stage_all is
used by itself and where native.bbclass is used with an autotooled
recipe with no do_stage changes. In those two cases we don't need to use
legacy mode.

Porting Guide
=============

There is a bb.debug in base.bbclass which tells us which functions are
using legacy staging functions. We can raise the profile of this message
as we work through the recipes dealing with the staging functions.

As a guide:

* Any do_stage where we do an autotools_stage_all can just be deleted.

* Any do_stage which matches the do_install can just be removed.

* Native packages with delete do_install should not anymore.

* Any do_stage function which installs extra things compared to
do_install is very suspect and needs an explanation of why. Most likely
do_install should be fixed and do_stage then deleted.

* If do_stage really needs to do something other than what is in
do_install a function should be written to operate on SYSROOT_DESTDIR
and that function should be appended to SYSROOT_PREPROCESS_FUNCS. There
are some -native binary special cases which will need this but almost
everything should *not* need this.

* Any other cases, post to the list and we'll work something out

Comments and experiments with the branch welcome. If I get some time
I'll try and start adding a few conversions to the branch.

FWIW in Poky I have about 25% legacy staging and 75% using the new
functions since I've been pushing autotools_stage there heavily the past
few months.

Cheers,

Richard

Re: Staging - time to end the current mess - now with patches

[Chris Larson]

On commits 4adf2f2 through 54d5f30:

Acked-by: Chris Larson <clarson@kergoth.com>

On Mon, Nov 2, 2009 at 3:09 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> This is much more interesting with patches so we now have:
>
> http://cgit.openembedded.net/cgit.cgi/openembedded/log/?h=rpurdie/work-in-progress
>
> I ended up cleaning a lot of stuff up as I went but the two really
> interesting things this branch contains are:
>
> a) Removal of the layout_* variables. This allows Poky's cross canadian
> SDK functionality to be merged. It also cleans up things quite a bit,
> I've not tested how the other canadian implementation fairs with this
> but the intent is to replace that with the Poky implementation which is
> much cleaner (no boatloads of duplicated variables and uses
> BBCLASSEXTEND).
>
> b) Change the way do_stage operates.
>
> The intent is that do_install installs to ${D}. Nothing should operate
> directly on ${D} other than the install.
>
> do_package takes a copy of ${D} into ${PKGD} and then runs the functions
> in PACKAGE_PREPROCESS_FUNCS which can alter this directory. The result
> is then packaged.
>
> do_stage detects if the do_stage function is defined. The default is
> there is no definition anymore. If it is defined we go into legacy mode
> which works like current staging, we take a lock, take a snapshot of
> staging, run do_stage, run any SYSROOT_PREPROCESS_FUNCS which operate
> against SYSROOT_DESTDIR="", see what changed, take a copy of the changes
> and release the lock.
>
> If we're not legacy, SYSROOT_DESTDIR=${WORKDIR}/sysroot-destdir, we copy
> ${D} into ${SYSROOT_DESTDIR}/${STAGING_DIR_TARGET}, we any
> SYSROOT_PREPROCESS_FUNCS against SYSROOT_DESTDIR, save the result for
> creating the staging package, take the staging lock and copy into
> staging ("install the package"), release the lock.
>
> For fun, we also detect two special cases - where autotools_stage_all is
> used by itself and where native.bbclass is used with an autotooled
> recipe with no do_stage changes. In those two cases we don't need to use
> legacy mode.
>
> Porting Guide
> =============
>
> There is a bb.debug in base.bbclass which tells us which functions are
> using legacy staging functions. We can raise the profile of this message
> as we work through the recipes dealing with the staging functions.
>
> As a guide:
>
> * Any do_stage where we do an autotools_stage_all can just be deleted.
>
> * Any do_stage which matches the do_install can just be removed.
>
> * Native packages with delete do_install should not anymore.
>
> * Any do_stage function which installs extra things compared to
> do_install is very suspect and needs an explanation of why. Most likely
> do_install should be fixed and do_stage then deleted.
>
> * If do_stage really needs to do something other than what is in
> do_install a function should be written to operate on SYSROOT_DESTDIR
> and that function should be appended to SYSROOT_PREPROCESS_FUNCS. There
> are some -native binary special cases which will need this but almost
> everything should *not* need this.
>
> * Any other cases, post to the list and we'll work something out
>
> Comments and experiments with the branch welcome. If I get some time
> I'll try and start adding a few conversions to the branch.
>
> FWIW in Poky I have about 25% legacy staging and 75% using the new
> functions since I've been pushing autotools_stage there heavily the past
> few months.
>
> Cheers,
>
> Richard
>
>
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



-- 
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.

Re: Staging - time to end the current mess - now with patches

[Stanislav Brabec]

Richard Purdie wrote:

I agree with the new concept. I did not understand, why we need
do_stage, if we can mangle and stage DESTDIR directly.

> do_package takes a copy of ${D} into ${PKGD} and then runs the functions
> in PACKAGE_PREPROCESS_FUNCS which can alter this directory. The result
> is then packaged.

Maybe do_mangle and do_mangle_append or so may look better from an user
aspect and easier to port (just move extra commands from do_stage to
do_mangle_append). But PACKAGE_PREPROCESS_FUNCS should be OK as well.

> * Any do_stage where we do an autotools_stage_all can just be deleted.

And autotools_stage class will become just autotools.

> * Native packages with delete do_install should not anymore.

Thinking about it, do still make separate native recipes sense after
this change? Most of them could recycle nearly the same recipe then.
(Specially patched utilities would be an exception.)

I can imagine, that native build will be built from the host recipe,
just with a different setup.

> * Any do_stage function which installs extra things compared to
> do_install is very suspect and needs an explanation of why. Most likely
> do_install should be fixed and do_stage then deleted.

I agree. Shorter file list in do_stage might have had some sense to save
few megabytes of unused stuff in staging dir, but it is a small profit
from the double work.

> * If do_stage really needs to do something other than what is in
> do_install a function should be written to operate on SYSROOT_DESTDIR
> and that function should be appended to SYSROOT_PREPROCESS_FUNCS. There
> are some -native binary special cases which will need this but almost
> everything should *not* need this.

Example of special case may be guile. Mangling of guile-config must be
done in a special way (guile-config is a guile script, not shell
script). I cannot remember any other recipe, that needs it.

> Comments and experiments with the branch welcome. If I get some time
> I'll try and start adding a few conversions to the branch.

It's a bit unrelated, but I would like to see temp/run.do_... script for
splitting install dir to sub-package dirs and packages and
temp/log.do_... with QA output that warns about unpackaged files.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: Staging - time to end the current mess - now with patches

[Richard Purdie]

On Wed, 2009-11-04 at 13:15 +0100, Stanislav Brabec wrote:
> Richard Purdie wrote:
> > do_package takes a copy of ${D} into ${PKGD} and then runs the functions
> > in PACKAGE_PREPROCESS_FUNCS which can alter this directory. The result
> > is then packaged.
> 
> Maybe do_mangle and do_mangle_append or so may look better from an user
> aspect and easier to port (just move extra commands from do_stage to
> do_mangle_append). But PACKAGE_PREPROCESS_FUNCS should be OK as well.

I have a slight preference for having specific defined functions rather
than concatenation of a load of different things.

I'm toying with the idea of renaming the whole idea of "stage" to
sysroot so we could have do_sysroot_package, do_sysroot_install and
do_sysroot_mangle. That could be a lot clearer for the user?

> > * Any do_stage where we do an autotools_stage_all can just be deleted.
> 
> And autotools_stage class will become just autotools.

Yes, it was always intended as a transition step and this would remove
the need for it.

> > * Native packages with delete do_install should not anymore.
> 
> Thinking about it, do still make separate native recipes sense after
> this change? Most of them could recycle nearly the same recipe then.
> (Specially patched utilities would be an exception.)
> 
> I can imagine, that native build will be built from the host recipe,
> just with a different setup.

I'm a step ahead here with BBCLASSEXTEND :). Since we have a new bitbake
release we can now bump the bitbake version dependency and start using
this. 

An example of its use:

http://git.pokylinux.org/cgit.cgi/poky/tree/meta/packages/mpfr/mpfr_2.3.1.bb

> > * Any do_stage function which installs extra things compared to
> > do_install is very suspect and needs an explanation of why. Most likely
> > do_install should be fixed and do_stage then deleted.
> 
> I agree. Shorter file list in do_stage might have had some sense to save
> few megabytes of unused stuff in staging dir, but it is a small profit
> from the double work.

We can always remove things from staging we know to be useless like docs
in a global/central function. Disk space is not a top consideration
though.

> > * If do_stage really needs to do something other than what is in
> > do_install a function should be written to operate on SYSROOT_DESTDIR
> > and that function should be appended to SYSROOT_PREPROCESS_FUNCS. There
> > are some -native binary special cases which will need this but almost
> > everything should *not* need this.
> 
> Example of special case may be guile. Mangling of guile-config must be
> done in a special way (guile-config is a guile script, not shell
> script). I cannot remember any other recipe, that needs it.

Ok, the framework shout fit that.

> > Comments and experiments with the branch welcome. If I get some time
> > I'll try and start adding a few conversions to the branch.
> 
> It's a bit unrelated, but I would like to see temp/run.do_... script for
> splitting install dir to sub-package dirs and packages and
> temp/log.do_... with QA output that warns about unpackaged files.

bitbake master does this already :)

Cheers,

Richard

Re: Staging - time to end the current mess - now with patches

[Stanislav Brabec]

Richard Purdie wrote:

> I'm toying with the idea of renaming the whole idea of "stage" to
> sysroot so we could have do_sysroot_package, do_sysroot_install and
> do_sysroot_mangle. That could be a lot clearer for the user?

It makes sense. But the sysroot directory itself has name "staging". It
would be nice to have consistent names.


>> It's a bit unrelated, but I would like to see temp/run.do_... script for
>> splitting install dir to sub-package dirs and packages and
>> temp/log.do_... with QA output that warns about unpackaged files.
>
>bitbake master does this already :)

Nice.

Well, just another trivial idea that can simplify life:

- files in temp/ and stamps/ can have number somewhere in its name - if
they will be sorted by name, then they will have its natural order.

-- 
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus