From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: questions about WORKDIR and S usage and files/ stuff
Date: Sun, 22 Feb 2015 15:25:07 -0500 (EST) [thread overview]
Message-ID: <alpine.LFD.2.11.1502221509270.29570@localhost> (raw)
In-Reply-To: <1424595258.11836.72.camel@linuxfoundation.org>
On Sun, 22 Feb 2015, Richard Purdie wrote:
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=4eb3db9a2ca8eaff64b64b8f56dac25d4734571c
>
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=cf72ede74d35746a10d0708942287548f9c72f30
>
> and some of the surrounding patches. I'd assumed base-files was part
> of that series, clearly it wasn't but there were many other recipes
> changed at that time.
ah, gotcha. so let me just summarize my understanding of this, it
looks pretty straightforward.
once upon a time, base.bbclass politely(?) auto-created the S
directory for each recipe. this had the potential for screwing things
up if the recipe author didn't set S properly for that recipe.
solution: stop auto-creating S, leaving the responsibility for
creating whatever S refers to to the recipe itself, typically as a
result of just doing a regular unpack of the SRC_URI. this allows a
trivial sanity check -- whatever directory S refers to should exist as
the result of the simple unpacking of that recipe.
now, given the default setting in bitbake.conf of
S = WORKDIR/BP
as long as that value is appropriate for a recipe, then the recipe
author need not set it explicitly. *but*, even in the case where a
recipe doesn't require any "unpacking" -- as in, recipes like
base-files which refer exclusively to local files -- it is still
necessary to set S to *something* that will exist, just to pass that
sanity test, and the easiest solution is to just set it to WORKDIR,
which is guaranteed to exist for *any* recipe.
final thought on this -- to pass the sanity check, it is necessary
only for the directory referred to by S to exist. the obvious thing to
set it to is, of course, WORKDIR, but in the case of recipes like
base-files which don't even *use* S, it's technically possible to set
it to *any* directory guaranteed to exist. i'm not suggesting this is
a smart thing to do, only that it would be technically viable.
and all this suggests that, even if you set S = WORKDIR, for
cleanliness, you should still avoid referring to unpacked objects
relative to S, just in case -- it's safer to restrict yourself to
referring to things relative to WORKDIR. is that about right?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
next prev parent reply other threads:[~2015-02-22 20:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-21 10:09 questions about WORKDIR and S usage and files/ stuff Robert P. J. Day
2015-02-21 12:34 ` Richard Purdie
2015-02-21 20:18 ` Robert P. J. Day
2015-02-21 20:28 ` Robert P. J. Day
2015-02-22 8:35 ` Robert P. J. Day
2015-02-22 8:54 ` Richard Purdie
2015-02-22 9:00 ` Robert P. J. Day
2015-02-22 20:25 ` Robert P. J. Day [this message]
2015-02-23 9:24 ` Paul Eggleton
2015-02-23 10:02 ` Robert P. J. Day
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=alpine.LFD.2.11.1502221509270.29570@localhost \
--to=rpjday@crashcourse.ca \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/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.