[poky] [PATCH] rm_work.bbclass: allow a shell var to override rm_work

[Frans Meulenbroeks]

2010/12/13 Tian, Kevin <kevin.tian at intel.com>:
>>From: Frans Meulenbroeks
>>Sent: Sunday, December 12, 2010 11:02 PM
>>
>>Sometimes one is building with rm_work, but for a specific build you want to
>>keep the work even if the build is successful.
>>One way to achieve this is to comment the INHERIT += "rm_work" from your
>>local.conf file, but this means that all recipes need to be reparsed which takes some time.
>>
>>This patch introduces a variable KEEP_WORK
>>If this variable is set the work will not be removed.
>>Intended use is
>>KEEP_WORK=1 bitbake yourrecipe.bb
>>Default behaviour is kept the same (in case KEEP_WORK is not set)
>>
>>Note that in order for this to work KEEP_WORK needs to be added to the env var
>>BB_ENV_EXTRAWHITE
>>e.g. export BB_ENV_EXTRAWHITE="KEEP_WORK"
>>
>>We still might want to improve the test so it only keeps the work if KEEP_WORK is > 0
>>(or do not execute the task at all if KEEP_WORK is not set).
>>Also we might want to add KEEP_WORK to the whitelist of vars that are always ok
>
> Is it useful to further extend this KEEP_WORK option to allow task-based selection?
> For example, I may only be interested on the sysroot installation path, and thus:
>
> KEEP_WORK="install populate_sysroot" bitbake yourrecipe.bb
>
> Currently the scope of rm_work is just binary: keep all or remove all. A finer granule
> control gives us flexibility to concentrate on several tasks which most likely causes
> trouble while still able to reduce the footprint.
>
> Comment? :-)
>
> Thanks
> Kevin
>
Seems a good plan to me, but it is beyond my capabilities to implement that.
It is useful to have an easy way to keep all though.
e.g. KEEP_WORK="all".
I don't think it is desirable to have to say
KEEP_WORK="configure compile install package ..." to keep all.

The typical use case for me is to keep either nothing because I want
to save space, or keep all because for some reason the package has an
issue or for some other reason I want to examine the log.
In the latter case I prefer having a little bit too much above having
a little bit too little.

Best regards, Frans