questions about WORKDIR and S usage and files/ stuff

questions about WORKDIR and S usage and files/ stuff

[Robert P. J. Day]

  some admittedly simple questions about the WORKDIR layout to make
sure i understand it *completely* as the basis for further questions.
(if all of this is documented in an OE or YP manual somewhere, that'd
be great.)

  from bitbake.conf, i can see the default setting for a recipe's
WORKDIR:

BASE_WORKDIR ?= "${TMPDIR}/work"
WORKDIR = "${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"

and, across all of the layers i have checked out, the only place i've
seen where a recipe changes that value is here:

openembedded-core/meta/recipes-devtools/gcc/gcc-source.inc:WORKDIR =
"${TMPDIR}/work-shared/gcc-${PV}-${PR}"

which makes sense since gcc is a special case -- in short, for any
kind of "normal" recipe, there is no compelling reason to ever mess
with the WORKDIR variable, is there?

  next, S, and its default value, again from bitbake.conf:

  S = "${WORKDIR}/${BP}"

as i read it (and i sure hope i understand this correctly), the S
directory is where a recipe's source is going to be unloaded and
patched, correct? and, AFAICT, setting this is a *choice* on the part
of the recipe author. leaving that value as it is seems to be
perfectly reasonable, or a recipe author can tweak it to some other
moderately-related value. i've seen numerous examples where, if the
SRC_URI refers to a git repo, the recipe author sets:

  S = "${WORKDIR}/git"

but, again, that's a *choice*, correct? just because you're cloning
from a git repo doesn't *require* you to set S that way, does it? is
there any standard OE convention or, more importantly, *requirement*
for the value of S depending on the recipe?

  moving on, when a recipe contains associated files in a files/ or
${PN}/ directory, as i read it, all of those files are always copied
directly into ${WORKDIR} for further processing, correct? as in, it
doesn't matter how you set S for that recipe, all files listed with
"file://" in the recipe's SRC_URI will be copied directly to
${WORKDIR}, yes? and those files fall into two major categories.

  if a file is a patch file (.diff,.patch suffix), it will be applied
automatically. if it's not a patch file, then it only makes sense if
the corresponding recipe manually and explicitly does something with
that file, correct? otherwise, there's no point in it being there.

  consider the obvious recipe for base-files -- that contains a
SRC_URI that reflects *nothing* but explicit files to populate the
destination ${D} directory, and each one of those files *must* be
manually installed in ${D} somewhere in the recipe, or there is no
point in that file in even being there, correct? (i ask this painfully
simple question because i *know* i've run across recipes that list a
non-patch file in SRC_URI that the recipe subsequently does nothing
with, and i always explain to students that that's a bit of an oddity
and probably represents a historical holdover.)

  sticking with those non-patch files, it makes sense that all of them
should be processed relative to their location in ${WORKDIR} (which is
where they've all been copied), but occasionally, i'll see a recipe
that sets:

  S = ${WORKDIR}

then refers to all those files relative to ${S}. sure, that'll work,
but it always struck me as dangerous in case you ever need to use a
separate S directory down the road, then you'd have to change the
entire recipe.

  as an example, consider base-files again, which sets:

  S = "${WORKDIR}"

but not for any reason that i can see since that recipe consists of
nothing but explicit files, and all of their processing is done with
respect to ${WORKDIR}, anyway, which strikes me as the right way to do
it. so, a question -- what is the point of the base-files recipe
setting S to that value? doesn't seem to have any purpose that i can
see.

  finally(?), i've seen a number of recipes that set:

  S = "${WORKDIR}"

even if they have a SRC_URI tarball *and* some accompanying files to
process. i'm *assuming* this is acceptable as long as the recipe
author knows that unloading both the tarball source and the files into
the same WORKDIR won't cause any name clashes, yes? it would seem to
always be cleaner to keep the source in a subdirectory, but if a
recipe author wants to mix everything in the same place, i guess
that's a possibility. is there any *compelling* reason to set S =
${WORKDIR}?

  i think that's it for now ... i just wanted to make sure i
completely understand this variable usage as the basis for the next
posting or two.

rday

p.s. i also notice that a small number of OE recipes contain the
apparently redundant setting:

$ grep -r "^S = \"\${WORKDIR}/\${BP}\"" *
meta/recipes-extended/texinfo/texinfo_4.8.bb:S = "${WORKDIR}/${BP}"
meta/recipes-extended/texinfo/texinfo_5.2.bb:S = "${WORKDIR}/${BP}"
meta/recipes-support/taglib/taglib_1.9.1.bb:S = "${WORKDIR}/${BP}"
$

which i would be tempted to remove, just because i'm a big fan of
minimalization.

-- 

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

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

Re: questions about WORKDIR and S usage and files/ stuff

[Richard Purdie]

On Sat, 2015-02-21 at 05:09 -0500, Robert P. J. Day wrote:
> which makes sense since gcc is a special case -- in short, for any
> kind of "normal" recipe, there is no compelling reason to ever mess
> with the WORKDIR variable, is there?

You'd probably break things if you did.

>   next, S, and its default value, again from bitbake.conf:
> 
>   S = "${WORKDIR}/${BP}"
> 
> as i read it (and i sure hope i understand this correctly), the S
> directory is where a recipe's source is going to be unloaded and
> patched, correct? and, AFAICT, setting this is a *choice* on the part
> of the recipe author. leaving that value as it is seems to be
> perfectly reasonable, or a recipe author can tweak it to some other
> moderately-related value. i've seen numerous examples where, if the
> SRC_URI refers to a git repo, the recipe author sets:
> 
>   S = "${WORKDIR}/git"
> 
> but, again, that's a *choice*, correct?

No, this is where the bitbake fetcher typically unpacks to. The git
fetcher module defaults to a directory called "git" in WORKDIR.

>  just because you're cloning
> from a git repo doesn't *require* you to set S that way, does it? is
> there any standard OE convention or, more importantly, *requirement*
> for the value of S depending on the recipe?

The S value is determined by the things in SRC_URI. A tarball usually
has the files in directory called ${BP} and when the fetcher extracts to
WORKDIR, the files end up in a directory called ${BP} as a result.

Not all tarballs follow that convention so the recipe sets this value as
appropriate.

>   moving on, when a recipe contains associated files in a files/ or
> ${PN}/ directory, as i read it, all of those files are always copied
> directly into ${WORKDIR} for further processing, correct? as in, it
> doesn't matter how you set S for that recipe, all files listed with
> "file://" in the recipe's SRC_URI will be copied directly to
> ${WORKDIR}, yes? and those files fall into two major categories.

*All* items in SRC_URI are unpacked to WORKDIR. Its just some create
subdirectories themselves (like tarballs or the git fetcher) since to do
otherwise would be more confusing.

If you change these values you will see things break.

>   if a file is a patch file (.diff,.patch suffix), it will be applied
> automatically. if it's not a patch file, then it only makes sense if
> the corresponding recipe manually and explicitly does something with
> that file, correct? otherwise, there's no point in it being there.

Correct.

>   consider the obvious recipe for base-files -- that contains a
> SRC_URI that reflects *nothing* but explicit files to populate the
> destination ${D} directory, and each one of those files *must* be
> manually installed in ${D} somewhere in the recipe, or there is no
> point in that file in even being there, correct? (i ask this painfully
> simple question because i *know* i've run across recipes that list a
> non-patch file in SRC_URI that the recipe subsequently does nothing
> with, and i always explain to students that that's a bit of an oddity
> and probably represents a historical holdover.)

Right, that is probably a mistake.

>   sticking with those non-patch files, it makes sense that all of them
> should be processed relative to their location in ${WORKDIR} (which is
> where they've all been copied), but occasionally, i'll see a recipe
> that sets:
> 
>   S = ${WORKDIR}
> 
> then refers to all those files relative to ${S}. sure, that'll work,
> but it always struck me as dangerous in case you ever need to use a
> separate S directory down the road, then you'd have to change the
> entire recipe.
> 
>   as an example, consider base-files again, which sets:
> 
>   S = "${WORKDIR}"
> 
> but not for any reason that i can see since that recipe consists of
> nothing but explicit files, and all of their processing is done with
> respect to ${WORKDIR}, anyway, which strikes me as the right way to do
> it. so, a question -- what is the point of the base-files recipe
> setting S to that value? doesn't seem to have any purpose that i can
> see.

See the recent patches which actually added that.

>   finally(?), i've seen a number of recipes that set:
> 
>   S = "${WORKDIR}"
> 
> even if they have a SRC_URI tarball *and* some accompanying files to
> process. i'm *assuming* this is acceptable as long as the recipe
> author knows that unloading both the tarball source and the files into
> the same WORKDIR won't cause any name clashes, yes? it would seem to
> always be cleaner to keep the source in a subdirectory, but if a
> recipe author wants to mix everything in the same place, i guess
> that's a possibility. is there any *compelling* reason to set S =
> ${WORKDIR}?

See the above recent patch series.

>   i think that's it for now ... i just wanted to make sure i
> completely understand this variable usage as the basis for the next
> posting or two.
> 
> rday
> 
> p.s. i also notice that a small number of OE recipes contain the
> apparently redundant setting:
> 
> $ grep -r "^S = \"\${WORKDIR}/\${BP}\"" *
> meta/recipes-extended/texinfo/texinfo_4.8.bb:S = "${WORKDIR}/${BP}"
> meta/recipes-extended/texinfo/texinfo_5.2.bb:S = "${WORKDIR}/${BP}"
> meta/recipes-support/taglib/taglib_1.9.1.bb:S = "${WORKDIR}/${BP}"
> $
> 
> which i would be tempted to remove, just because i'm a big fan of
> minimalization.

Those can likely be cleaned up, yes. Patches welcome.

Cheers,

Richard

Re: questions about WORKDIR and S usage and files/ stuff

[Robert P. J. Day]

  i'll finalize all this a bit at a time ... thanks for your time in
clearing all this up.

On Sat, 21 Feb 2015, Richard Purdie wrote:

> On Sat, 2015-02-21 at 05:09 -0500, Robert P. J. Day wrote:
> > which makes sense since gcc is a special case -- in short, for any
> > kind of "normal" recipe, there is no compelling reason to ever
> > mess with the WORKDIR variable, is there?
>
> You'd probably break things if you did.

  good ... so my guidance will be, don't mess with WORKDIR or evil
things will happen. students like that sort of advice.

> >   next, S, and its default value, again from bitbake.conf:
> >
> >   S = "${WORKDIR}/${BP}"
> >
> > as i read it (and i sure hope i understand this correctly), the S
> > directory is where a recipe's source is going to be unloaded and
> > patched, correct? and, AFAICT, setting this is a *choice* on the part
> > of the recipe author. leaving that value as it is seems to be
> > perfectly reasonable, or a recipe author can tweak it to some other
> > moderately-related value. i've seen numerous examples where, if the
> > SRC_URI refers to a git repo, the recipe author sets:
> >
> >   S = "${WORKDIR}/git"
> >
> > but, again, that's a *choice*, correct?
>
> No, this is where the bitbake fetcher typically unpacks to. The git
> fetcher module defaults to a directory called "git" in WORKDIR.
>
> >  just because you're cloning from a git repo doesn't *require* you
> > to set S that way, does it? is there any standard OE convention
> > or, more importantly, *requirement* for the value of S depending
> > on the recipe?
>
> The S value is determined by the things in SRC_URI. A tarball
> usually has the files in directory called ${BP} and when the fetcher
> extracts to WORKDIR, the files end up in a directory called ${BP} as
> a result.
>
> Not all tarballs follow that convention so the recipe sets this
> value as appropriate.

  ah, suddenly it's all clear ... the destination unpack (S) directory
is determined by the type of fetching being done. in the case of
tarballs, the default of ${WORKDIR}/${BP} is simply based on the fact
that that's the most common top-level directory name used in creating
those tarballs in the first place. if a different top-level name is
used, it's the responsibility of the recipe's author to know what it
is and set S accordingly. (i've actually never written a recipe from
scratch so embarrassed to admit i didn't know that.)

> >   moving on, when a recipe contains associated files in a files/
> > or ${PN}/ directory, as i read it, all of those files are always
> > copied directly into ${WORKDIR} for further processing, correct?
> > as in, it doesn't matter how you set S for that recipe, all files
> > listed with "file://" in the recipe's SRC_URI will be copied
> > directly to ${WORKDIR}, yes? and those files fall into two major
> > categories.
>
> *All* items in SRC_URI are unpacked to WORKDIR. Its just some create
> subdirectories themselves (like tarballs or the git fetcher) since
> to do otherwise would be more confusing.
>
> If you change these values you will see things break.

  good, that's what i thought.

> >   if a file is a patch file (.diff,.patch suffix), it will be
> > applied automatically. if it's not a patch file, then it only
> > makes sense if the corresponding recipe manually and explicitly
> > does something with that file, correct? otherwise, there's no
> > point in it being there.
>
> Correct.

  thought so ... and i *know* i've seen recipes which have local files
in the SRC_URI that don't seem to be referenced in the recipe. no
harm, of course, probably just historical holdovers someone forgot to
remove.

rday

-- 

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

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

Re: questions about WORKDIR and S usage and files/ stuff

[Robert P. J. Day]

On Sat, 21 Feb 2015, Richard Purdie wrote:

> On Sat, 2015-02-21 at 05:09 -0500, Robert P. J. Day wrote:

> > p.s. i also notice that a small number of OE recipes contain the
> > apparently redundant setting:
> >
> > $ grep -r "^S = \"\${WORKDIR}/\${BP}\"" *
> > meta/recipes-extended/texinfo/texinfo_4.8.bb:S = "${WORKDIR}/${BP}"
> > meta/recipes-extended/texinfo/texinfo_5.2.bb:S = "${WORKDIR}/${BP}"
> > meta/recipes-support/taglib/taglib_1.9.1.bb:S = "${WORKDIR}/${BP}"
> > $
> >
> > which i would be tempted to remove, just because i'm a big fan of
> > minimalization.
>
> Those can likely be cleaned up, yes. Patches welcome.

  i'll put something together ...

rday

-- 

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

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

Re: questions about WORKDIR and S usage and files/ stuff

[Robert P. J. Day]

On Sat, 21 Feb 2015, Richard Purdie wrote:

> On Sat, 2015-02-21 at 05:09 -0500, Robert P. J. Day wrote:

... snip ...

> >   sticking with those non-patch files, it makes sense that all of
> > them should be processed relative to their location in ${WORKDIR}
> > (which is where they've all been copied), but occasionally, i'll
> > see a recipe that sets:
> >
> >   S = ${WORKDIR}
> >
> > then refers to all those files relative to ${S}. sure, that'll
> > work, but it always struck me as dangerous in case you ever need
> > to use a separate S directory down the road, then you'd have to
> > change the entire recipe.
> >
> >   as an example, consider base-files again, which sets:
> >
> >   S = "${WORKDIR}"
> >
> > but not for any reason that i can see since that recipe consists
> > of nothing but explicit files, and all of their processing is done
> > with respect to ${WORKDIR}, anyway, which strikes me as the right
> > way to do it. so, a question -- what is the point of the
> > base-files recipe setting S to that value? doesn't seem to have
> > any purpose that i can see.
>
> See the recent patches which actually added that.

  sorry, i don't know what recent patches you're talking about ...
that variable setting above has, according to git blame, been part of
the base-files recipe since back in 2005.

  what am i misunderstanding?

rday

-- 

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

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

Re: questions about WORKDIR and S usage and files/ stuff

[Richard Purdie]

On Sun, 2015-02-22 at 03:35 -0500, Robert P. J. Day wrote:
> On Sat, 21 Feb 2015, Richard Purdie wrote:
> 
> > On Sat, 2015-02-21 at 05:09 -0500, Robert P. J. Day wrote:
> 
> ... snip ...
> 
> > >   sticking with those non-patch files, it makes sense that all of
> > > them should be processed relative to their location in ${WORKDIR}
> > > (which is where they've all been copied), but occasionally, i'll
> > > see a recipe that sets:
> > >
> > >   S = ${WORKDIR}
> > >
> > > then refers to all those files relative to ${S}. sure, that'll
> > > work, but it always struck me as dangerous in case you ever need
> > > to use a separate S directory down the road, then you'd have to
> > > change the entire recipe.
> > >
> > >   as an example, consider base-files again, which sets:
> > >
> > >   S = "${WORKDIR}"
> > >
> > > but not for any reason that i can see since that recipe consists
> > > of nothing but explicit files, and all of their processing is done
> > > with respect to ${WORKDIR}, anyway, which strikes me as the right
> > > way to do it. so, a question -- what is the point of the
> > > base-files recipe setting S to that value? doesn't seem to have
> > > any purpose that i can see.
> >
> > See the recent patches which actually added that.
> 
>   sorry, i don't know what recent patches you're talking about ...
> that variable setting above has, according to git blame, been part of
> the base-files recipe since back in 2005.
> 
>   what am i misunderstanding?

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.

Cheers,

Richard

Re: questions about WORKDIR and S usage and files/ stuff

[Robert P. J. Day]

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, there we go, thank you kindly.

rday

-- 

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

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

Re: questions about WORKDIR and S usage and files/ stuff

[Robert P. J. Day]

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
========================================================================

Re: questions about WORKDIR and S usage and files/ stuff

[Paul Eggleton]

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.

>   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.

>   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. You should use S 
to point to the actual source for the recipe, though. S is actually used.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: 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
========================================================================