All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Yang <liezhi.yang@windriver.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: bitbake-devel@lists.openembedded.org, Zhenfeng.Zhao@windriver.com
Subject: Re: [PATCH 0/1] bitbake-whatchanged: print what is about to happen
Date: Wed, 8 Aug 2012 17:26:51 +0800	[thread overview]
Message-ID: <502230DB.30405@windriver.com> (raw)
In-Reply-To: <3338596.LFW82p3Yzv@helios>


On 08/08/2012 05:12 PM, Paul Eggleton wrote:
> On Wednesday 08 August 2012 11:40:14 Robert Yang wrote:
>> On 08/08/2012 05:01 AM, Richard Purdie wrote:
>>> On Tue, 2012-08-07 at 18:12 +0100, Paul Eggleton wrote:
>>>> A couple of other things:
>>>>
>>>> 1) We ought to be able to assume that TMPDIR is the same regardless of
>>>> the recipe specified; this avoids having to parse all of the recipes just
>>>> to get the value of this variable.
>>
>> I'm sorry, I don't understand what did you mean here. it seems that what
>> I did is the same as you said: Use "bitbake -e" to figure out the TMPDIR at
>> the beginning, then use it elsewhere.
>
> Sorry, I wasn't being very clear. If you specify the recipe with bitbake -e,
> bitbake has to go through a parse of the recipes (retrieving from the cache if
> available of course, but even that still takes a few seconds). I'm suggesting
> you don't specify the recipe as TMPDIR shouldn't be recipe-specific, and save
> quite a bit of time.
>
>>>> 2) I'm a little concerned with the general approach - is there no way of
>>>> avoiding having to copy and move around the stamps directory? It seems
>>>> a little risky if nothing else.
>>>
>>> I think adding a parameter to -S would be a good move for this, its
>>> something people likely want in conjunction with that.
>>
>> Yes, add a parameter to "bitbake -S recipe" would be the correct way, but
>> as far as I know, the "-S" is a bool option currently, it doesn't accept
>> an argument, I think that we have the following 2 solutions:
>>

Got it, thanks.

>> 1) Modify the "-S" to accept an argument, but this may break the the usage
>>      of the "bitbake -S", the currently usage is:
>>
>>      bitbake -S <recipe>
>>
>>      We may change it to:
>>
>>      bitbake -S <tmpdir>(or stampsdir) <recipe>
>>
>>      But it seems that it's not easy differentiate the argument behind "-S".
>
> I have to admit I'm not sure what -S is currently being used for; so it's hard
> for me to comment on what might get broken if we change this. I suspect it's
> not being used very much at all though.
>
>> 2) Use "TMPDIR(or STAMP)=<path> bitbake -S recipe", but we don't support it
>>      currently, but we can add an os.getenv("TMPDIR") in bitbake to achieve
>> it, the BB_TMPDIR or BB_STAMP would be better, but I'm not sure whether it
>> will cause other problems.
>>
>> I'd like to send a patch for 2) if you are OK with it.
>
> We already have a mechanism to allow through variables from the environment -
> BB_ENV_WHITELIST / BB_ENV_EXTRAWHITE, and we should make use of that in
> preference to os.getenv(). I think we would not want this change in stamp
> writing behaviour to take effect unless -S is being used though, which suggests
> it ought to be a new variable that is not checked unless -S has been specified.
>

Thank you very much, I will add a BB_DUMP_STAMP.

// Robert

> Cheers,
> Paul
>




  reply	other threads:[~2012-08-08  9:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-07 15:48 [PATCH 0/1] bitbake-whatchanged: print what is about to happen Robert Yang
2012-08-07 15:48 ` [PATCH 1/1] " Robert Yang
2012-08-07 17:12 ` [PATCH 0/1] " Paul Eggleton
2012-08-07 21:01   ` Richard Purdie
2012-08-08  3:40     ` Robert Yang
2012-08-08  9:12       ` Paul Eggleton
2012-08-08  9:26         ` Robert Yang [this message]
2012-08-08  9:17       ` Robert Yang
2012-08-08  9:21       ` Richard Purdie
2012-08-08  9:41         ` Robert Yang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=502230DB.30405@windriver.com \
    --to=liezhi.yang@windriver.com \
    --cc=Zhenfeng.Zhao@windriver.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=paul.eggleton@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.