Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Thu, 6 Dec 2012, Chris Larson wrote:
On Thu, Dec 6, 2012 at 4:16 PM, Robert P. J. Day rpj...@crashcourse.ca
wrote:
ok, that's just silly (but that could be the 9% quebec beer
talking). if i'm working with just one layer, then this:
FILESEXTRAPATHS_prepend := rday
works fine:
FILESPATH=rday/linux-gnueabi:rday/arm:rday/build-linux:rday/pn-netbase:...
if that fails with more than one layer, then that is, quite simply,
asinine.
I really don't see why you're failing to grasp such a basic concept
as a colon separated variable. Do you think you can add something to
PATH without adding a colon?
arrr ... i'll try this again. as i read it (and i'm
willing to be corrected), the value of FILESEXTRAPATHS_prepend is not
used for a simple, textual prepend. period. end of discussion.
rather, it is used as the basis for extending FILESPATH based on
*processing* that involves taking the value of OVERRIDES into
consideration. using the example i was talking about yesterday (the
meta-ti layer and the netbase recipe), if my netbase .bbappend
contains *only* this:
FILESEXTRAPATHS_prepend := /rday
then if i use bitbake-env to see what happens with FILESPATH wrt to
that recipe, i see (replacing : with newlines for prettiness):
$ bitbake-env -r netbase FILESPATH | tr : '\n'
Parsing recipes..done.
# FILESPATH=${@base_set_filespath([${FILE_DIRNAME}/${BP},
${FILE_DIRNAME}/${BPN}, ${FILE_DIRNAME}/files], d)}
FILESPATH=/rday/linux-gnueabi
/rday/arm
/rday/build-linux
/rday/pn-netbase
/rday/dm814x-evm
/rday/ti814x
/rday/armv7a
/rday/
/rday/class-target
/rday/forcevariable
/rday/libc-glibc
/rday/
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/linux-gnueabi
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/arm
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/build-linux
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/pn-netbase
... snip ...
see? how much clearer can i make this? if you prefer adding the
silly colon to that line, as in:
FILESEXTRAPATHS_prepend := /rday:
it ends up making exactly *no* difference. none. zip. squat.
you're quite welcome to add as many as you like:
FILESEXTRAPATHS_prepend := /rday:
and it will make no difference since, as i read it, you are not
specifying a value to be literally prepended to FILESPATH, you are
identifying a *directory* to be processed (by, i believe, def
base_set_filespath(path, d) in utils.bbclass). if for some bizarre
reason you like to add that superfluous :, knock yourself out, but
don't claim that it is somehow *necessary* because of a
colon-separated list of directories.
on the other hand, it *is* useful if you want to add, say, *two*
dirtectories, as in:
FILESEXTRAPATHS_prepend := /rday1:/rday2
which will produce (predictably):
FILESPATH=/rday1/linux-gnueabi
/rday1/arm
/rday1/build-linux
/rday1/pn-netbase
/rday1/dm814x-evm
/rday1/ti814x
/rday1/armv7a
/rday1/
/rday1/class-target
/rday1/forcevariable
/rday1/libc-glibc
/rday1/
/rday2/linux-gnueabi
/rday2/arm
/rday2/build-linux
/rday2/pn-netbase
/rday2/dm814x-evm
/rday2/ti814x
/rday2/armv7a
/rday2/
/rday2/class-target
/rday2/forcevariable
/rday2/libc-glibc
/rday2/
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/linux-gnueabi
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/arm
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/build-linux
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/pn-netbase
... snip ...
so why am i so fixated on this? thanks for asking.
i find the current, widespread usage of this form (with the colon):
FILESEXTRAPATHS_prepend := ${THISDIR}/patches:
potentially misleading since people reading the .bbappend file will
(quite naturally) assume that, hey, that must represent a literal
prepend since it includes the colon. and they will be wrong. in
fact, i'm willing to bet that, based on that ubiquitous usage, many
people who wrote .bbappend files had no idea that that's what was
happening.
i'm willing to bet that, in many cases, those people just added what
they thought was a simple overriding directory name, having no clue
that that was being expanded into multiple directories, one of which
just *happened* to match the directory name they supplied. so things
worked out, but not for the reason they thought.
as it stands, the way things are done now will work just fine, of
course. but i think it's visually misleading, and not very well
explained.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn:
Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Friday 07 December 2012 08:04:58 Robert P. J. Day wrote:
On Thu, 6 Dec 2012, Chris Larson wrote:
On Thu, Dec 6, 2012 at 4:16 PM, Robert P. J. Day rpj...@crashcourse.ca
wrote:
ok, that's just silly (but that could be the 9% quebec beer
talking). if i'm working with just one layer, then this:
FILESEXTRAPATHS_prepend := rday
works fine:
FILESPATH=rday/linux-gnueabi:rday/arm:rday/build-linux:rday/pn-netb
ase:...
if that fails with more than one layer, then that is, quite simply,
asinine.
I really don't see why you're failing to grasp such a basic concept
as a colon separated variable. Do you think you can add something to
PATH without adding a colon?
arrr ... i'll try this again. as i read it (and i'm
willing to be corrected), the value of FILESEXTRAPATHS_prepend is not
used for a simple, textual prepend. period. end of discussion.
rather, it is used as the basis for extending FILESPATH based on
*processing* that involves taking the value of OVERRIDES into
consideration. using the example i was talking about yesterday (the
meta-ti layer and the netbase recipe), if my netbase .bbappend
contains *only* this:
FILESEXTRAPATHS_prepend := /rday
then if i use bitbake-env to see what happens with FILESPATH wrt to
that recipe, i see (replacing : with newlines for prettiness):
$ bitbake-env -r netbase FILESPATH | tr : '\n'
Parsing recipes..done.
# FILESPATH=${@base_set_filespath([${FILE_DIRNAME}/${BP},
${FILE_DIRNAME}/${BPN}, ${FILE_DIRNAME}/files], d)}
FILESPATH=/rday/linux-gnueabi
/rday/arm
/rday/build-linux
/rday/pn-netbase
/rday/dm814x-evm
/rday/ti814x
/rday/armv7a
/rday/
/rday/class-target
/rday/forcevariable
/rday/libc-glibc
/rday/
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/li
nux-gnueabi
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/a
rm
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/b
uild-linux
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/p
n-netbase ... snip ...
see? how much clearer can i make this? if you prefer adding the
silly colon to that line, as in:
FILESEXTRAPATHS_prepend := /rday:
it ends up making exactly *no* difference. none. zip. squat.
you're quite welcome to add as many as you like:
FILESEXTRAPATHS_prepend := /rday:
and it will make no difference since, as i read it, you are not
specifying a value to be literally prepended to FILESPATH, you are
identifying a *directory* to be processed (by, i believe, def
base_set_filespath(path, d) in utils.bbclass). if for some bizarre
reason you like to add that superfluous :, knock yourself out, but
don't claim that it is somehow *necessary* because of a
colon-separated list of directories.
on the other hand, it *is* useful if you want to add, say, *two*
dirtectories, as in:
FILESEXTRAPATHS_prepend := /rday1:/rday2
Right, and this is what you'll get if two layers bbappend the same recipe and
both prepend to FILESEXTRAPATHS, which is not an unlikely situation. If you
want that to work correctly then you *must* include the trailing colon. The
easiest thing is to just include it every time you prepend to FILESEXTRAPATHS.
which will produce (predictably):
FILESPATH=/rday1/linux-gnueabi
/rday1/arm
/rday1/build-linux
/rday1/pn-netbase
/rday1/dm814x-evm
/rday1/ti814x
/rday1/armv7a
/rday1/
/rday1/class-target
/rday1/forcevariable
/rday1/libc-glibc
/rday1/
/rday2/linux-gnueabi
/rday2/arm
/rday2/build-linux
/rday2/pn-netbase
/rday2/dm814x-evm
/rday2/ti814x
/rday2/armv7a
/rday2/
/rday2/class-target
/rday2/forcevariable
/rday2/libc-glibc
/rday2/
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/li
nux-gnueabi
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/a
rm
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/b
uild-linux
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/p
n-netbase ... snip ...
so why am i so fixated on this? thanks for asking.
i find the current, widespread usage of this form (with the colon):
FILESEXTRAPATHS_prepend := ${THISDIR}/patches:
potentially misleading since people reading the .bbappend file will
(quite naturally) assume that, hey, that must represent a literal
prepend since it includes the colon.
It *is* a literal prepend - to FILESEXTRAPATHS. In your discussion above you
are conflating FILESPATH with FILESEXTRAPATHS. The former is constructed based
on the latter in conjuction with OVERRIDES; they are not the same variable.
i'm willing to bet that, in many cases, those people just added what
they thought was a simple overriding directory name, having no clue
that that was being expanded into multiple directories, one of which
Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Fri, 7 Dec 2012, Paul Eggleton wrote:
On Friday 07 December 2012 08:04:58 Robert P. J. Day wrote:
i find the current, widespread usage of this form (with the colon):
FILESEXTRAPATHS_prepend := ${THISDIR}/patches:
potentially misleading since people reading the .bbappend file will
(quite naturally) assume that, hey, that must represent a literal
prepend since it includes the colon.
It *is* a literal prepend - to FILESEXTRAPATHS. In your discussion
above you are conflating FILESPATH with FILESEXTRAPATHS. The former
is constructed based on the latter in conjuction with OVERRIDES;
they are not the same variable.
ok, i think i finally clued in here, thanks. i was fixated on the
processing when only *one* bbappend file was involved, i didn't think
to back up another level.
my bad. apologies.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] FILESEXTRAPATHS needs to be explained *way* better
first time digging into FILESPATH and .bbappend files, and i tested
the effect of setting something trivial to see what would happen:
FILESEXTRAPATHS_prepend := rday
did this for netbase in meta-ti layer, and checked the resulting
value of FILESPATH and (nicely formatted so you can read it), i got:
FILESPATH=rday/linux-gnueabi
rday/arm
rday/build-linux
rday/pn-netbase
rday/beagleboard
rday/omap3
rday/armv7a
rday/
rday/class-target
rday/forcevariable
rday/libc-glibc
rday/
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/linux-gnueabi
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/arm
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/build-linux
/home/rpjday/OE/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/pn-netbase
... snip ...
that is totally *not* what i expected given the explanation of that
variable in the current docs (unless i've missed it). obviously,
FILESEXTRAPATHS doesn't just add individual directories to FILESPATH
-- it processes and adds based on OVERRIDES, which is fine but that's
not at all obvious.
in addition, there is absolutely no need to add a : to the value
as the processing adds that for you, so the many, many examples of
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
is potentially confusing to folks reading the code. (that trailing
: doesn't hurt, but it has no value.)
at what point is this variable explained in detail?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day rpj...@crashcourse.cawrote:
in addition, there is absolutely no need to add a : to the value
as the processing adds that for you, so the many, many examples of
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
is potentially confusing to folks reading the code. (that trailing
: doesn't hurt, but it has no value.)
This is wrong. You only don't need the leading : if FILESEXTRAPATHS was
empty to begin with, which is only the case if that is the first and only
bbappend adding to it. As soon as you get more than one, you'll end up with
concatenated values and no separator.
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Thu, 6 Dec 2012, Chris Larson wrote:
On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day rpj...@crashcourse.ca
wrote:
in addition, there is absolutely no need to add a : to the value
as the processing adds that for you, so the many, many examples of
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
is potentially confusing to folks reading the code. (that trailing
: doesn't hurt, but it has no value.)
This is wrong. You only don't need the leading : if FILESEXTRAPATHS
was empty to begin with, which is only the case if that is the first
and only bbappend adding to it. As soon as you get more than one,
you'll end up with concatenated values and no separator.
i'm confused, not sure what this means. what is the *proper* usage
of that variable?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Thu, Dec 6, 2012 at 3:32 PM, Robert P. J. Day rpj...@crashcourse.cawrote:
On Thu, 6 Dec 2012, Chris Larson wrote:
On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day rpj...@crashcourse.ca
wrote:
in addition, there is absolutely no need to add a : to the
value
as the processing adds that for you, so the many, many examples of
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
is potentially confusing to folks reading the code. (that trailing
: doesn't hurt, but it has no value.)
This is wrong. You only don't need the leading : if FILESEXTRAPATHS
was empty to begin with, which is only the case if that is the first
and only bbappend adding to it. As soon as you get more than one,
you'll end up with concatenated values and no separator.
i'm confused, not sure what this means. what is the *proper* usage
of that variable?
As I'm pretty sure you've already been told in one of the other 2 threads
about this, it's a colon separated list of paths. If you go appending to it
without a separator, you're going to end up with something useless.
layer1/.../foo.bbappend
FILESEXTRAPATHS_prepend = ${THISDIR}/foo
layer2/.../foo.bbappend
FILESEXTRAPATHS_prepend = ${THISDIR}/bar
resulting FILESEXTRAPATHS: layer1/.../foo/layer2/.../bar
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On 2012-12-06 15:32, Robert P. J. Day wrote:
On Thu, 6 Dec 2012, Chris Larson wrote:
On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day rpj...@crashcourse.ca wrote:
in addition, there is absolutely no need to add a : to the value
as the processing adds that for you, so the many, many examples of
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
is potentially confusing to folks reading the code. (that trailing
: doesn't hurt, but it has no value.)
This is wrong. You only don't need the leading : if FILESEXTRAPATHS
was empty to begin with, which is only the case if that is the first
and only bbappend adding to it. As soon as you get more than one,
you'll end up with concatenated values and no separator.
i'm confused, not sure what this means. what is the *proper* usage
of that variable?
I think Chris means you don't need :=, you should just use =
Bottom line, what you are trying to create is something that looks like this:
FILESEXTRAPATHS = some_path:some_other_path:even_another_path:
so the : at the end of the expression should always be there.
--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Thu, Dec 6, 2012 at 3:49 PM, Gary Thomas g...@mlbassoc.com wrote:
On 2012-12-06 15:32, Robert P. J. Day wrote:
On Thu, 6 Dec 2012, Chris Larson wrote:
On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day rpj...@crashcourse.ca
wrote:
in addition, there is absolutely no need to add a : to the
value
as the processing adds that for you, so the many, many examples of
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
is potentially confusing to folks reading the code. (that
trailing
: doesn't hurt, but it has no value.)
This is wrong. You only don't need the leading : if FILESEXTRAPATHS
was empty to begin with, which is only the case if that is the first
and only bbappend adding to it. As soon as you get more than one,
you'll end up with concatenated values and no separator.
i'm confused, not sure what this means. what is the *proper* usage
of that variable?
I think Chris means you don't need :=, you should just use =
No, := is required whenever you use THISDIR in a bbappend, unless you
*really* mean the path to the recipe itself, which is unlikely. THISDIR
evaluates based on FILE, which resolves to the current file being parsed,
at the time it's expanded.
Bottom line, what you are trying to create is something that looks like
this:
FILESEXTRAPATHS = some_path:some_other_path:**even_another_path:
so the : at the end of the expression should always be there.
Right :)
--
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Thu, 6 Dec 2012, Chris Larson wrote:
On Thu, Dec 6, 2012 at 3:32 PM, Robert P. J. Day rpj...@crashcourse.ca
wrote:
On Thu, 6 Dec 2012, Chris Larson wrote:
On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day
rpj...@crashcourse.ca
wrote:
in addition, there is absolutely no need to add a : to the
value
as the processing adds that for you, so the many, many examples
of
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
is potentially confusing to folks reading the code. (that
trailing
: doesn't hurt, but it has no value.)
This is wrong. You only don't need the leading : if FILESEXTRAPATHS
was empty to begin with, which is only the case if that is the first
and only bbappend adding to it. As soon as you get more than one,
you'll end up with concatenated values and no separator.
i'm confused, not sure what this means. what is the *proper* usage
of that variable?
As I'm pretty sure you've already been told in one of the other 2
threads about this, it's a colon separated list of paths. If you go
appending to it without a separator, you're going to end up with
something useless.
layer1/.../foo.bbappend
FILESEXTRAPATHS_prepend = ${THISDIR}/foo
layer2/.../foo.bbappend
FILESEXTRAPATHS_prepend = ${THISDIR}/bar
resulting FILESEXTRAPATHS: layer1/.../foo/layer2/.../bar
ok, that's just silly (but that could be the 9% quebec beer
talking). if i'm working with just one layer, then this:
FILESEXTRAPATHS_prepend := rday
works fine:
FILESPATH=rday/linux-gnueabi:rday/arm:rday/build-linux:rday/pn-netbase:...
if that fails with more than one layer, then that is, quite simply,
asinine.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FILESEXTRAPATHS needs to be explained *way* better
On Thu, Dec 6, 2012 at 4:16 PM, Robert P. J. Day rpj...@crashcourse.cawrote: ok, that's just silly (but that could be the 9% quebec beer talking). if i'm working with just one layer, then this: FILESEXTRAPATHS_prepend := rday works fine: FILESPATH=rday/linux-gnueabi:rday/arm:rday/build-linux:rday/pn-netbase:... if that fails with more than one layer, then that is, quite simply, asinine. I really don't see why you're failing to grasp such a basic concept as a colon separated variable. Do you think you can add something to PATH without adding a colon? -- Christopher Larson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
