[OE-core] wanting to confirm understanding of FILESPATH in .bb and .inc files
Paul Eggleton
paul.eggleton at linux.intel.com
Mon Nov 11 15:18:27 UTC 2013
Hi Robert,
On Monday 11 November 2013 05:34:20 Robert P. J. Day wrote:
> currently poking around for examples of recipes' use of FILESPATH to
> use in class, and i just want to make absolutely sure i understand its
> usage since some recipes seem to use it in weird and/or unnecessary
> ways. (using the current poky tarball 10.0.0 for this.)
>
> first, i can see the default setting of FILESPATH in base.bbclass:
>
> FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}",
> "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
>
> which, for any recipe, creates a FILESPATH that starts with top-level
> subdirectories of ${BP}, ${BPN} and "files" and, on top of that,
> extends each one with further subdirectories as defined by the
> variable FILESOVERRIDES. so, as a working example, i can use "bb show"
> to display the value of FILESPATH for, say, the zlib recipe, which
> shows me a path with 15 entries (exactly as i expected building for my
> beagleboard xm):
>
> FILESPATH="/home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib
> -1.2.8/arm
> /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib-1.2.8/arm
> v7a
> /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib-1.2.8/bea
> gleboard
> /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib-1.2.8/pok
> y /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib-1.2.8/
> /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib/arm
> /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib/armv7a
> /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib/beagleboa
> rd /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib/poky
> /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/zlib/
> /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/files/arm
> /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/files/armv7a
> /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/files/beaglebo
> ard /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/files/poky
> /home/rpjday/oe/dora/poky-dora-10.0.0/meta/recipes-core/zlib/files/"
>
> so far, so good, and here's where i want the clarification.
>
> as long as a recipe has "file://" references that occur exclusively
> in any of the directories listed above, there should be no reason to
> *need* to override FILESPATH, correct? however, some recipe or include
> files clearly do just that, and i want to make sure that what i'm
> seeing in files like that is *optional*, and not required due to some
> subtlety i'm unaware of.
>
> consider first example:
>
> systemtap_git.inc:FILESPATH = "${FILE_DIRNAME}/systemtap"
>
> it would seem that this setting is superfluous since that entry is
> already in the default value of FILESPATH for that recipe, so i'm
> guessing that the benefit of the above is to simply reduce the size of
> FILESPATH for efficiency? i mean, technically, the above didn't need
> to be set, did it?
I think the reason that is there is because systemtap_git.inc is used in
another recipe which would not have that path included automatically, i.e.
systemtap-uprobes_git.bb. It could be argued that systemtap-uprobes_git.bb
should be extending the path instead, that would also work.
> another example is with "-native" recipes. consider:
>
> qemu-helper-native_1.0.bb:FILESPATH = "${FILE_DIRNAME}/qemu-helper"
>
> again, that seems redundant since:
>
> $ bb show -r qemu-helper-native BP BPN
> Parsing recipes..done.
> # BP=${BPN}-${PV}
> BP="qemu-helper-1.0"
> # BPN=${@base_prune_suffix(d.getVar('PN', True),
> d.getVar('SPECIAL_PKGSUFFIX', True).split(), d)} BPN="qemu-helper"
> $
>
> so that entry is already part of FILESPATH.
Right, that would appear to be redundant.
FWIW, I did open a bug about the general case here:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4497
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
More information about the Openembedded-core
mailing list