kernel manual: confusing coverage of FILESEXTRAPATHS_prepend

kernel manual: confusing coverage of FILESEXTRAPATHS_prepend

[Robert P. J. Day]

  minor quibble about kernel dev manual -- section 2.2.1, "creating
the append file", uses the example of:

 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

while section 2.2.3 uses:

 FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

both sections kind of implying that that's the way to do it, without
making it clear that *either* way works as long as the variable
prepend matches up with the directory name.

  both ways are correct, of course, but the wording is a bit
confusing.

rday

-- 

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

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

Re: kernel manual: confusing coverage of FILESEXTRAPATHS_prepend

[Joe MacDonald]

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

[[yocto] kernel manual: confusing coverage of FILESEXTRAPATHS_prepend] On 15.02.25 (Wed 03:54) Robert P. J. Day wrote:

> 
>   minor quibble about kernel dev manual -- section 2.2.1, "creating
> the append file", uses the example of:
> 
>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> 
> while section 2.2.3 uses:
> 
>  FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> 
> both sections kind of implying that that's the way to do it, without
> making it clear that *either* way works as long as the variable
> prepend matches up with the directory name.
> 
>   both ways are correct, of course, but the wording is a bit
> confusing.

It's probably worth changing the latter reference to match the former.
Both work but with any new recipes (at least in the layers I maintain)
the preference is to use the former for clarity as well as faster
lookups.

-J.

> 
> rday
> 
> -- 
> 
> ========================================================================
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
> 
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ========================================================================
-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]

Re: kernel manual: confusing coverage of FILESEXTRAPATHS_prepend

[Gary Thomas]

On 2015-02-25 06:44, Joe MacDonald wrote:
> [[yocto] kernel manual: confusing coverage of FILESEXTRAPATHS_prepend] On 15.02.25 (Wed 03:54) Robert P. J. Day wrote:
>
>>
>>    minor quibble about kernel dev manual -- section 2.2.1, "creating
>> the append file", uses the example of:
>>
>>   FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>
>> while section 2.2.3 uses:
>>
>>   FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>>
>> both sections kind of implying that that's the way to do it, without
>> making it clear that *either* way works as long as the variable
>> prepend matches up with the directory name.
>>
>>    both ways are correct, of course, but the wording is a bit
>> confusing.
>
> It's probably worth changing the latter reference to match the former.
> Both work but with any new recipes (at least in the layers I maintain)
> the preference is to use the former for clarity as well as faster
> lookups.

What makes one way faster than any other?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: kernel manual: confusing coverage of FILESEXTRAPATHS_prepend

[Rifenbark, Scott M]

I updated and published the change to the 1.8 version.  I took Joe's suggestion. 

Thanks, 
Scott

>-----Original Message-----
>From: yocto-bounces@yoctoproject.org [mailto:yocto-
>bounces@yoctoproject.org] On Behalf Of Joe MacDonald
>Sent: Wednesday, February 25, 2015 5:44 AM
>To: Robert P. J. Day
>Cc: Yocto discussion list
>Subject: Re: [yocto] kernel manual: confusing coverage of
>FILESEXTRAPATHS_prepend
>
>[[yocto] kernel manual: confusing coverage of FILESEXTRAPATHS_prepend]
>On 15.02.25 (Wed 03:54) Robert P. J. Day wrote:
>
>>
>>   minor quibble about kernel dev manual -- section 2.2.1, "creating
>> the append file", uses the example of:
>>
>>  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>
>> while section 2.2.3 uses:
>>
>>  FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>>
>> both sections kind of implying that that's the way to do it, without
>> making it clear that *either* way works as long as the variable
>> prepend matches up with the directory name.
>>
>>   both ways are correct, of course, but the wording is a bit
>> confusing.
>
>It's probably worth changing the latter reference to match the former.
>Both work but with any new recipes (at least in the layers I maintain) the
>preference is to use the former for clarity as well as faster lookups.
>
>-J.
>
>>
>> rday
>>
>> --
>>
>>
>===========================================================
>=============
>> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>>                         http://crashcourse.ca
>>
>> Twitter:                                       http://twitter.com/rpjday
>> LinkedIn:                               http://ca.linkedin.com/in/rpjday
>>
>===========================================================
>===========
>> ==
>--
>-Joe MacDonald.
>:wq

Re: kernel manual: confusing coverage of FILESEXTRAPATHS_prepend

[Darren Hart]

On 2/25/15, 12:54 AM, "Robert P. J. Day" <rpjday@crashcourse.ca> wrote:

>
>  minor quibble about kernel dev manual -- section 2.2.1, "creating
>the append file", uses the example of:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
>while section 2.2.3 uses:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>
>both sections kind of implying that that's the way to do it, without
>making it clear that *either* way works as long as the variable
>prepend matches up with the directory name.
>
>  both ways are correct, of course, but the wording is a bit
>confusing.

Thanks, I agree, the same syntax should be used throughout the document.
The FILESEXTRAPATHS variable does correctly link to the ref manual where
people can get details on usage.

For simplicity, I should using "files" instead of ${PN}, it avoids the
"make sure your directory name matches ${PN}" issue.


-- 
Darren Hart
Intel Open Source Technology Center

Re: kernel manual: confusing coverage of FILESEXTRAPATHS_prepend

[Robert P. J. Day]

On Wed, 25 Feb 2015, Joe MacDonald wrote:

> [[yocto] kernel manual: confusing coverage of FILESEXTRAPATHS_prepend] On 15.02.25 (Wed 03:54) Robert P. J. Day wrote:
>
> >
> >   minor quibble about kernel dev manual -- section 2.2.1, "creating
> > the append file", uses the example of:
> >
> >  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> >
> > while section 2.2.3 uses:
> >
> >  FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> >
> > both sections kind of implying that that's the way to do it, without
> > making it clear that *either* way works as long as the variable
> > prepend matches up with the directory name.
> >
> >   both ways are correct, of course, but the wording is a bit
> > confusing.
>
> It's probably worth changing the latter reference to match the
> former. Both work but with any new recipes (at least in the layers I
> maintain) the preference is to use the former for clarity as well as
> faster lookups.

  sort of related to this, but in a *regular* recipe (not a bbappend),
the default FILESPATH is set in base.bbclass:

FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}",
"${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"

so that, by default, a regular recipe will look for SRC_URI entries in
*all* of:

1) ${BP}/
2) ${BPN}/
3) "files/"

it's not clear which is the preferred standard (not sure there even
*is* a preferred standard), but in cases where more than one of the
above exists, all of the relevant directories will be searched, but
it's not clear why some recipes insist on breaking up the files over
more than one directory.

  in the case of subversion, i can see the logic:

subversion/
subversion_1.6.15.bb
subversion-1.8.11/
subversion_1.8.11.bb

so that the generic "subversion/" directory will apply to *all*
subversion recipes, but there is also the version-specific
"subversion-1.8.11/", so that's fine.

  busybox, though:

busybox/
busybox_1.23.1.bb
busybox_git.bb
busybox.inc
files/

won't both directories busybox/ and files/ always be consulted for
SRC_URI entries, regardless of the version of busybox? so what is the
rationale for breaking those files over two directories?

  and i'm curious ... is there any recipe that contains all *three*
types of SRC_URI subdirectories?

rday

-- 

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

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

Re: kernel manual: confusing coverage of FILESEXTRAPATHS_prepend

[Robert P. J. Day]

On Thu, 26 Feb 2015, Robert P. J. Day wrote:

  ... snip ...

>   sort of related to this, but in a *regular* recipe (not a bbappend),
> the default FILESPATH is set in base.bbclass:
>
> FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}",
> "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
>
> so that, by default, a regular recipe will look for SRC_URI entries in
> *all* of:
>
> 1) ${BP}/
> 2) ${BPN}/
> 3) "files/"
>
> it's not clear which is the preferred standard (not sure there even
> *is* a preferred standard), but in cases where more than one of the
> above exists, all of the relevant directories will be searched, but
> it's not clear why some recipes insist on breaking up the files over
> more than one directory.
>
>   in the case of subversion, i can see the logic:
>
> subversion/
> subversion_1.6.15.bb
> subversion-1.8.11/
> subversion_1.8.11.bb
>
> so that the generic "subversion/" directory will apply to *all*
> subversion recipes, but there is also the version-specific
> "subversion-1.8.11/", so that's fine.
>
>   busybox, though:
>
> busybox/
> busybox_1.23.1.bb
> busybox_git.bb
> busybox.inc
> files/
>
> won't both directories busybox/ and files/ always be consulted for
> SRC_URI entries, regardless of the version of busybox? so what is the
> rationale for breaking those files over two directories?
>
>   and i'm curious ... is there any recipe that contains all *three*
> types of SRC_URI subdirectories?

  just to follow up on this, as a demo of how to add a directory of
SRC_URI files to a basic recipe, i want to show a variety of
possibilities, from simple to complex.

  in the simplest case, there will be a single directory, which will
be named one of BP, BPN, or "files", all of which are equally valid --
lots of examples of this.

  slightly more complex -- a multi-version recipe directory with each
recipe version having its own version-specific directory, like
coreutils:

coreutils-6.9/
coreutils_6.9.bb
coreutils-8.23/
coreutils_8.23.bb

  more complicated -- recipes with *both* version-specific and generic
directories like, say, readline:

files/
readline-5.2/
readline_5.2.bb
readline-6.3/
readline_6.3.bb
readline.inc

etc, etc. when this is explained in the appropriate YP manual, is it
clear the variety you can have?

rday

-- 

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

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

Re: kernel manual: confusing coverage of FILESEXTRAPATHS_prepend

[Paul Eggleton]

On Thursday 26 February 2015 04:12:33 Robert P. J. Day wrote:
> On Wed, 25 Feb 2015, Joe MacDonald wrote:
> > [[yocto] kernel manual: confusing coverage of FILESEXTRAPATHS_prepend] On 
15.02.25 (Wed 03:54) Robert P. J. Day wrote:
> > >   minor quibble about kernel dev manual -- section 2.2.1, "creating
> > > 
> > > the append file", uses the example of:
> > >  FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> > > 
> > > while section 2.2.3 uses:
> > >  FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> > > 
> > > both sections kind of implying that that's the way to do it, without
> > > making it clear that *either* way works as long as the variable
> > > prepend matches up with the directory name.
> > > 
> > >   both ways are correct, of course, but the wording is a bit
> > > 
> > > confusing.
> > 
> > It's probably worth changing the latter reference to match the
> > former. Both work but with any new recipes (at least in the layers I
> > maintain) the preference is to use the former for clarity as well as
> > faster lookups.
> 
>   sort of related to this, but in a *regular* recipe (not a bbappend),
> the default FILESPATH is set in base.bbclass:
> 
> FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}",
> "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
> 
> so that, by default, a regular recipe will look for SRC_URI entries in
> *all* of:
> 
> 1) ${BP}/
> 2) ${BPN}/
> 3) "files/"
> 
> it's not clear which is the preferred standard (not sure there even
> *is* a preferred standard), but in cases where more than one of the
> above exists, all of the relevant directories will be searched, but
> it's not clear why some recipes insist on breaking up the files over
> more than one directory.
> 
>   in the case of subversion, i can see the logic:
> 
> subversion/
> subversion_1.6.15.bb
> subversion-1.8.11/
> subversion_1.8.11.bb
> 
> so that the generic "subversion/" directory will apply to *all*
> subversion recipes, but there is also the version-specific
> "subversion-1.8.11/", so that's fine.
> 
>   busybox, though:
> 
> busybox/
> busybox_1.23.1.bb
> busybox_git.bb
> busybox.inc
> files/
> 
> won't both directories busybox/ and files/ always be consulted for
> SRC_URI entries, regardless of the version of busybox? so what is the
> rationale for breaking those files over two directories?
> 
>   and i'm curious ... is there any recipe that contains all *three*
> types of SRC_URI subdirectories?

Our policy in OE-Core (and the layers under meta-openembedded) is to move away 
from files/ to ${BPN} for a bit of consistency - if you use ${BPN} it then 
doesn't matter if you have more than one recipe in a directory, the files for 
each recipe are still kept separate instead of a files/ directory with a 
mixture of files for different recipes. ${BP} would only be used for patches 
that are specific to a version where multiple versioned recipes are being 
provided, leading to multiple versions of the same files needing to be present.

We have been doing the "conversion" on a piecemeal basis on recipe upgrade 
however so that's why you will see files/ still in various places. To avoid 
undue churn I don't think it would be worth doing a mass rename, and it's also 
unlikely that we will be taking away the ability to use files/ by default, so 
other layers are free to do as they wish.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: kernel manual: confusing coverage of FILESEXTRAPATHS_prepend

[Robert P. J. Day]

On Thu, 26 Feb 2015, Paul Eggleton wrote:

> Our policy in OE-Core (and the layers under meta-openembedded) is to
> move away from files/ to ${BPN} for a bit of consistency - if you
> use ${BPN} it then doesn't matter if you have more than one recipe
> in a directory, the files for each recipe are still kept separate
> instead of a files/ directory with a mixture of files for different
> recipes. ${BP} would only be used for patches that are specific to a
> version where multiple versioned recipes are being provided, leading
> to multiple versions of the same files needing to be present.

  ok, so ... ${BPN} for single-recipe directories *or* common files
across multi-version recipes, and ${BP} for version-specific stuff?
that's the way i'm reading that. that's good, it's the sort of thing
that would be good in a "style guide."

rday

-- 

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

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