FILESEXTRAPATHS needs to be explained *way* better

FILESEXTRAPATHS needs to be explained *way* better

[Robert P. J. Day]

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

Re: FILESEXTRAPATHS needs to be explained *way* better

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day <rpjday@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.
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 1050 bytes --]

Re: FILESEXTRAPATHS needs to be explained *way* better

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1282 bytes --]

On Thu, 6 Dec 2012, Chris Larson wrote:

>
>
> On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day <rpjday@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
========================================================================

Re: FILESEXTRAPATHS needs to be explained *way* better

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]

On Thu, Dec 6, 2012 at 3:32 PM, Robert P. J. Day <rpjday@crashcourse.ca>wrote:

> On Thu, 6 Dec 2012, Chris Larson wrote:
>
> >
> >
> > On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day <rpjday@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

[-- Attachment #2: Type: text/html, Size: 2248 bytes --]

Re: FILESEXTRAPATHS needs to be explained *way* better

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2369 bytes --]

On Thu, 6 Dec 2012, Chris Larson wrote:

>
>
> On Thu, Dec 6, 2012 at 3:32 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>       On Thu, 6 Dec 2012, Chris Larson wrote:
>
>       >
>       >
>       > On Thu, Dec 6, 2012 at 2:59 PM, Robert P. J. Day <rpjday@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
========================================================================

Re: FILESEXTRAPATHS needs to be explained *way* better

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On Thu, Dec 6, 2012 at 4:16 PM, Robert P. J. Day <rpjday@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?
-- 
Christopher Larson

[-- Attachment #2: Type: text/html, Size: 987 bytes --]

Re: FILESEXTRAPATHS needs to be explained *way* better

[Robert P. J. Day]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5272 bytes --]

On Thu, 6 Dec 2012, Chris Larson wrote:

> On Thu, Dec 6, 2012 at 4:16 PM, Robert P. J. Day <rpjday@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?

  arrrrrrrgggghhhh ... 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:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: FILESEXTRAPATHS needs to be explained *way* better

[Paul Eggleton]

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 <rpjday@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?
> 
>   arrrrrrrgggghhhh ... 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
> just *happened* to match the directory name they supplied.  so things
> worked out, but not for the reason they thought.

By saying "just happened" you're implying that it is somehow accidental or 
incidental that the directory that the user has specified is added - it is 
nothing of the sort. It is completely deliberate and if it did not do so in 
fact almost no recipe that used this construct would work.

We know this isn't a particularly self-evident structure; if it makes it 
easier, consider it as just a single line of boilerplate when you want to add 
or override any file in SRC_URI within a bbappend.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: FILESEXTRAPATHS needs to be explained *way* better

[Robert P. J. Day]

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

Re: FILESEXTRAPATHS needs to be explained *way* better

[Gary Thomas]

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 <rpjday@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
------------------------------------------------------------

Re: FILESEXTRAPATHS needs to be explained *way* better

[Chris Larson]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

On Thu, Dec 6, 2012 at 3:49 PM, Gary Thomas <gary@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 <rpjday@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

[-- Attachment #2: Type: text/html, Size: 2504 bytes --]