Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Cc: "Rifenbark, Scott M" <scott.m.rifenbark@intel.com>
Subject: Re: "${bindir}" versus "${bindir}/*" ??
Date: Sat, 24 Mar 2012 11:26:36 +0000	[thread overview]
Message-ID: <1332588396.9740.518.camel@ted> (raw)
In-Reply-To: <alpine.DEB.2.02.1203240558370.23984@oneiric>

On Sat, 2012-03-24 at 06:01 -0400, Robert P. J. Day wrote:
> On Sat, 24 Mar 2012, Richard Purdie wrote:
> 
> > On Sat, 2012-03-24 at 04:40 -0400, Robert P. J. Day wrote:
> > > in bitbake.conf, numerous variables like "FILES_${PN}" are
> > > initialized with a combination of directory variables, with two
> > > different forms:
> > >
> > >   * ${bindir}
> > >   * ${bindir}/*
> > >
> > > is there a functional difference between those two?  my wildly
> > > speculative guess is that if "*" works as it does in the shell, it
> > > would simply skip any hidden objects.  is that the difference?  since
> > > i don't see that clarified anywhere.
> >
> > The former is recursive and the latter is not and will just match files
> > in the directory (unhidden ones at that).
> 
>   ah, that clears up so much.  i'm actually embarrassed to ask such
> obvious questions -- is that written up somewhere that i should have
> run across it before asking about it?
> 
> rday
> 
> p.s.  By "unhidden ones at that," i'm assuming you mean *only*
> unhidden ones?  so that its behaviour is entirely consistent with what
> people would expect?

I'm not passing judgement on that :).

Keep in mind that the whole system grew fairly organically more so at
some times that others and there are a ton on inconsistencies,
particularly when you get deeply into the system. I think OE-Core has
fixed a lot of details and has concentrated on the most user visible
ones but there are more things that could be cleaned up. I doubt we ever
will have a totally consistent system and I suspect if we did we'd hurt
the power and flexibility which are some of the bigger assets of the
project.

FWIW, the behaviour of the FILES_* variables uses python's globbing
functionality behind the scenes. If you know that it helps to understand
it:

http://docs.python.org/library/glob.html
(which in turn refers you to shell expansion which is something most
people are familiar with).

I think what I'd ask is where you find these things, ask questions and
get answers (such as the info about python glob above), can you please
try and document it somewhere?

Even if this is in the form of a Q&A type document it would perhaps save
the information and someone like Scott Rifenbark could then go through
this when he was time and integrate it into the manuals (assuming you
don't want to send him direct patches for that). This particular change
would make a good addition to:

http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-FILES

I'd also add that I sometimes hate the fact we use glob for FILES since
it does limit some of the things you can do. .debug directories are a
pet hate of mine in that regard.

Cheers,

Richard





  reply	other threads:[~2012-03-24 11:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-24  8:40 "${bindir}" versus "${bindir}/*" ?? Robert P. J. Day
2012-03-24  9:45 ` Richard Purdie
2012-03-24 10:01   ` Robert P. J. Day
2012-03-24 11:26     ` Richard Purdie [this message]
2012-03-24 12:37       ` Robert P. J. Day

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=1332588396.9740.518.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=scott.m.rifenbark@intel.com \
    /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