Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: wanting to confirm understanding of FILESPATH in .bb and .inc files
Date: Mon, 11 Nov 2013 15:18:27 +0000	[thread overview]
Message-ID: <1938763.4DceAK3YzM@helios> (raw)
In-Reply-To: <alpine.DEB.2.02.1311110437360.9099@oneiric>

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


      reply	other threads:[~2013-11-11 15:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-11 10:34 wanting to confirm understanding of FILESPATH in .bb and .inc files Robert P. J. Day
2013-11-11 15:18 ` Paul Eggleton [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1938763.4DceAK3YzM@helios \
    --to=paul.eggleton@linux.intel.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=rpjday@crashcourse.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox