[yocto] 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