rm_work.bbclass: inhibit rm_work per recipe

PATCH In review [email protected] 5 participants 10 messages Mar 13, 2013 – Apr 9, 2013

lore

Share & tools

lore

[email protected]

author

2013-03-13 07:17 UTC #0 lore raw

cover rm_work.bbclass: inhibit rm_work per recipe

From: Chen Qi <[email protected]>

The following changes since commit 365eb9b5d22208c967dcd91d8ab52faed20f04b5:

bitbake: bitbake-layers: fix duplicated help info (2013-03-10 04:36:52 +0000)

are available in the git repository at:

git://git.pokylinux.org/poky-contrib ChenQi/rm_work
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/rm_work

Chen Qi (1):
rm_work.bbclass: inhibit rm_work per recipe

 meta/classes/rm_work.bbclass |   13 +++++++++++++
 1 file changed, 13 insertions(+)

Signature · 1 line

1.7.9.5

[email protected]

author

2013-03-13 07:17 UTC #1 lore raw

PATCH 1/1 rm_work.bbclass: inhibit rm_work per recipe

From: Chen Qi <[email protected]>

Use RM_WORK_WHITELIST to inhibit rm_work per recipe. In this way, one can use rm_work for the most of the recipes but still keep the work area for the recipe(s) one is working on.

As an example, the following settings in local.conf will inhibit rm_work for icu-native, icu and busybox.

    INHERIT += "rm_work"
    RM_WORK_WHITELIST += "icu-native icu busybox"

If we comment out the RM_WORK_WHITELIST line and do a rebuild, the working area of these recipes will be cleaned up.

[YOCTO #3675]

Signed-off-by Chen Qi <[email protected]>

---
 meta/classes/rm_work.bbclass |   13 +++++++++++++
 1 file changed, 13 insertions(+)

meta/classes/rm_work.bbclass +13 -0

index d3be0be..54287bf 100644
@@ -5,6 +5,11 @@
 #
 # INHERIT += "rm_work"
 #
+# To inhibit rm_work for some recipes, specify them in RM_WORK_WHITELIST.
+# For example, in conf/local.conf:
+#
+# RM_WORK_WHITELIST += "icu-native icu busybox"
+#
 
 # Use the completion scheduler by default when rm_work is active
 # to try and reduce disk usage

@@ -14,6 +19,14 @@ RMWORK_ORIG_TASK := "${BB_DEFAULT_TASK}"
 BB_DEFAULT_TASK = "rm_work_all"
 
 do_rm_work () {
+    # If the recipe name is in the RM_WORK_WHITELIST, skip the recipe.
+    for p in ${RM_WORK_WHITELIST}; do
+        if [ "$p" = "${PN}" ]; then
+            bbnote "rm_work: Skipping ${PN} since it is in RM_WORK_WHITELIST"
+            exit 0
+        fi
+    done
+
     cd ${WORKDIR}
     for dir in *
     do

Signature · 1 line

1.7.9.5

Paul Eggleton

2013-03-26 17:29 UTC #2 lore raw

Quoted 6 lines · On Wednesday 13 March 2013 15:01:33 [email protected] wrote:

From: Chen Qi <[email protected]>
Use RM_WORK_WHITELIST to inhibit rm_work per recipe. In this way, one can use rm_work for the most of the recipes but still keep the work area for the recipe(s) one is working on.

Quoted 7 lines

As an example, the following settings in local.conf will inhibit rm_work for icu-native, icu and busybox.
    INHERIT += "rm_work"
    RM_WORK_WHITELIST += "icu-native icu busybox"
If we comment out the RM_WORK_WHITELIST line and do a rebuild, the working area of these recipes will be cleaned up.

This is a great feature, but I just looked at it and realised that the term "whitelist" isn't really correct - this is more of a blacklist.

The question is does it matter? If so we should probably change it now before it becomes too hard to change...

Cheers,
Paul

Signature · 2 lines

Paul Eggleton
Intel Open Source Technology Centre

Burton, Ross

2013-03-26 17:33 UTC #3 lore raw

Quoted 5 lines · Paul Eggleton

This is a great feature, but I just looked at it and realised that the term "whitelist" isn't really correct - this is more of a blacklist.
The question is does it matter? If so we should probably change it now before it becomes too hard to change...

A variable called WHITELIST that is actually a blacklist should be changed asap before we make a release, imho.

Ross

Phil Blundell

2013-03-26 17:43 UTC #4 lore raw

In reply to Paul Eggleton

Quoted 12 lines · Paul Eggleton

Quoted 11 lines · On Wednesday 13 March 2013 15:01:33 [email protected] wrote:
From: Chen Qi <[email protected]>
Use RM_WORK_WHITELIST to inhibit rm_work per recipe. In this way, one can use rm_work for the most of the recipes but still keep the work area for the recipe(s) one is working on.
As an example, the following settings in local.conf will inhibit rm_work for icu-native, icu and busybox.
    INHERIT += "rm_work"
    RM_WORK_WHITELIST += "icu-native icu busybox"

Quoted 5 lines

Quoted 2 lines
If we comment out the RM_WORK_WHITELIST line and do a rebuild, the working area of these recipes will be cleaned up.
This is a great feature, but I just looked at it and realised that the term "whitelist" isn't really correct - this is more of a blacklist.

This doesn't seem (at the risk of invoking an unintended metaphor) entirely black or white. Maybe it should just be "RM_WORK_EXCEPTIONS" or something.

Of course, you can get the same effect in your distro configuration by saying:

RM_WORK = "rm_work"
RM_WORK_pn-icu-native = ""
INHERIT += "${RM_WORK}"

so I must admit to being slightly ambivalent about whether the extra syntactic sugar is all that valuable. And then again you can always use rm_old_work instead. :-)

Paul Eggleton

2013-03-26 18:09 UTC #5 lore raw

Quoted 3 lines · On Tuesday 26 March 2013 17:25:52 Phil Blundell wrote:

This doesn't seem (at the risk of invoking an unintended metaphor) entirely black or white. Maybe it should just be "RM_WORK_EXCEPTIONS" or something.

"exception" has another meaning to my mind. I've sent out a patch to change it to RM_WORK_EXCLUDE.

Quoted 9 lines

Of course, you can get the same effect in your distro configuration by saying:
RM_WORK = "rm_work"
RM_WORK_pn-icu-native = ""
INHERIT += "${RM_WORK}"
so I must admit to being slightly ambivalent about whether the extra syntactic sugar is all that valuable.

True, that works; I think having an explicit variable makes it easier to understand what's going on though and is a little harder to typo and have your work removed when you didn't want it to be ;)

Quoted 1 line

And then again you can always use rm_old_work instead. :-)

I'm sure this has come up before, but is rm_old_work something we ought to have in OE-Core?

Cheers,
Paul

Signature · 2 lines

Paul Eggleton
Intel Open Source Technology Centre

Phil Blundell

2013-04-09 21:18 UTC #6 lore raw

Quoted 2 lines · Paul Eggleton

I'm sure this has come up before, but is rm_old_work something we ought to have in OE-Core?

Obviously it's not for me to say, but I suspect probably not. It requires ${WORKDIR} to follow a particular pattern, which not everybody will necessarily want, and I don't think you could really argue that it represents "core" functionality either.

Martin Jansa

2013-04-09 23:13 UTC #7 lore raw

Quoted 6 lines · Phil Blundell

Quoted 2 lines · Paul Eggleton
I'm sure this has come up before, but is rm_old_work something we ought to have in OE-Core?
Obviously it's not for me to say, but I suspect probably not. It requires ${WORKDIR} to follow a particular pattern, which not everybody

That pattern is now default in oe-core:
commit 05075cf3138d1c61f5cf4fe0e1a4587acc00c692

Author: Richard Purdie <[email protected]>
Date:   Fri Nov 16 15:35:53 2012 +0000

bitbake.conf/sanity: Separate versions and PN stamp components into
separate directories for WORKDIR and STAMP

Quoted 2 lines

will necessarily want, and I don't think you could really argue that it represents "core" functionality either.

I think that in some cases it's more useful then rm_work.

IMHO only missing part is good documentation (or better name) describing rm_work/rm_work_old difference:

1) rm_work is much better for builds in tmpfs
2) rm_work_old is better then rm_work if you have enough space to keep 1 WORKDIR for each component you're building

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

Martin Jansa

2013-03-26 18:12 UTC #8 lore raw

In reply to Paul Eggleton

Quoted 12 lines · Paul Eggleton

Quoted 11 lines · On Wednesday 13 March 2013 15:01:33 [email protected] wrote:
From: Chen Qi <[email protected]>
Use RM_WORK_WHITELIST to inhibit rm_work per recipe. In this way, one can use rm_work for the most of the recipes but still keep the work area for the recipe(s) one is working on.
As an example, the following settings in local.conf will inhibit rm_work for icu-native, icu and busybox.
    INHERIT += "rm_work"
    RM_WORK_WHITELIST += "icu-native icu busybox"

Quoted 8 lines

Quoted 2 lines
If we comment out the RM_WORK_WHITELIST line and do a rebuild, the working area of these recipes will be cleaned up.
This is a great feature, but I just looked at it and realised that the term "whitelist" isn't really correct - this is more of a blacklist.
The question is does it matter? If so we should probably change it now before it becomes too hard to change...

I got similar question yesterday about BB_HASHBASE_WHITELIST:

'And why is it called "WHITELIST"? Shouldn't things that are excluded be in a "BLACKLIST"?'

Maybe term WHITELIST isn't correct in both of them, at least they are consistent as it is now :).

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

Paul Eggleton

2013-03-26 18:20 UTC #9 lore raw

Quoted 24 lines · On Tuesday 26 March 2013 18:55:14 Martin Jansa wrote:

Quoted 16 lines · Paul Eggleton
Quoted 6 lines · On Wednesday 13 March 2013 15:01:33 [email protected] wrote:
From: Chen Qi <[email protected]>
Use RM_WORK_WHITELIST to inhibit rm_work per recipe. In this way, one can use rm_work for the most of the recipes but still keep the work area for the recipe(s) one is working on.
Quoted 8 lines
As an example, the following settings in local.conf will inhibit rm_work for icu-native, icu and busybox.
    INHERIT += "rm_work"
    RM_WORK_WHITELIST += "icu-native icu busybox"
If we comment out the RM_WORK_WHITELIST line and do a rebuild, the working area of these recipes will be cleaned up.
Quoted 6 lines
This is a great feature, but I just looked at it and realised that the term
"whitelist" isn't really correct - this is more of a blacklist.
The question is does it matter? If so we should probably change it now before it becomes too hard to change...

Quoted 7 lines

I got similar question yesterday about BB_HASHBASE_WHITELIST:
'And why is it called "WHITELIST"? Shouldn't things that are excluded be in a "BLACKLIST"?'
Maybe term WHITELIST isn't correct in both of them, at least they are consistent as it is now :)

You may well be right... BB_HASHBASE_WHITELIST has been around for so long though that I don't think we could consider changing it.

Cheers,
Paul

Signature · 2 lines

Paul Eggleton
Intel Open Source Technology Centre