[OE-core] questions about WORKDIR and S usage and files/ stuff

[Robert P. J. Day]

On Mon, 23 Feb 2015, Paul Eggleton wrote:

> On Sunday 22 February 2015 15:25:07 Robert P. J. Day wrote:
> > On Sun, 22 Feb 2015, Richard Purdie wrote:
> > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=4eb3db9a2ca8eaff64b64
> > > b8f56dac25d4734571c
> > >
> > > http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=cf72ede74d35746a10d07
> > > 08942287548f9c72f30
> > >
> > > 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.
>
> Yes, but this is not generally good advice for every recipe. If the
> main source for your recipe unpacks to a subdirectory then that is
> where you should point S to.

  oh, i understand that ... i was referring specifically to just those
recipes which *don't* unpack to any subdirectory, things like
base-files and so on. *obviously*, if a recipe unpacks, say, a tarball
to a subdirectory, it's your responsibility to make sure S is set
properly.

> >   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.
>
> In theory, but why is that of any interest? You seem to be looking
> at this from the perspective of just passing the sanity test, but
> the sanity test is there for a reason - so that you set it to a
> proper value, not to just any old value to make the warning go away.

  oh, i get that. my point (obviously badly phrased) was that, in the
case of recipes like base-files where the entire content of the recipe
is represented exclusively by local files supplied by the recipe (and
which will be unpacked directly under WORKDIR), in order to pass the
sanity test, you still need to supply a value for S that represents a
directory that will exist, even if the recipe itself makes no use of
it. the obvious value is, of course, WORKDIR -- my point was that, if
you wanted to be deliberately perverse, for recipes like that, you
could set S to *any* existing directory to pass the sanity test. that
would be a massively silly thing to do ... i'm just saying that it
would work. oh, wait ... just reading the last para ...

> >   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?
>
> For individual files that don't actually get unpacked, sure.

  ok, this is the style issue i was getting at ... even if you have a
recipe for which S = WORKDIR, if the recipe is manually processing
those local files, it should refer to them relative to WORKDIR, not S,
just in case ... who knows, maybe someday the recipe is modified to
actually unpack a tarball or something, and suddenly you need to go
through and fix everything.

  base-files is a good example of this -- all local files are referred
to relative to WORKDIR. on the other hand, the recipe for, say,
formfactor, violates that "style":

S = "${WORKDIR}"

PACKAGE_ARCH = "${MACHINE_ARCH}"
INHIBIT_DEFAULT_DEPS = "1"

do_install() {
        # Install file only if it has contents
        install -d ${D}${sysconfdir}/formfactor/
        install -m 0644 ${S}/config ${D}${sysconfdir}/formfactor/
        if [ -s "${S}/machconfig" ]; then
                install -m 0644 ${S}/machconfig ${D}${sysconfdir}/formfactor/
        fi
}

  again, technically correct, but i would have used WORKDIR in place
of S.

> You should use S to point to the actual source for the recipe,
> though. S is actually used.

  ah ... where? i'm quite willing to be convinced that it's necessary
for S = WORKDIR for recipes like this, i would just like to see why.
thanks.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================