[oe] [RFC] Bring PREFERRED_LIBC to all distros

[Richard Purdie]

On Mon, 2009-05-11 at 09:03 +0200, Koen Kooi wrote:
> On 11-05-09 00:36, Tom Rini wrote:
> > On Sun, May 10, 2009 at 07:27:42PM -0300, Otavio Salvador wrote:
> >> Hello Tom,
> >>
> >> On Sun, May 10, 2009 at 6:51 PM, Tom Rini<trini at embeddedalley.com>  wrote:
> >>> Not too wierd looking?  Otherwise, is there somewhere we can do,
> >>> roughly, sort -u, on ${OVERRIDES} ?  And not require a new bitbake for
> >>> everyone?
> 
> How do you decide which one to drop? The one with a lower or higher 
> priority? You can see how that gets real ugly real fast.
> 
> >> I belive that we shouldn't add hacks into OE recipes to avoid the
> >> requirement of new bitbake. If someone is using dev tree we can assume
> >> that this person can also use a development version from bitbake
> >> stable branch.
> >
> > I don't mean a hack to glibc*.bb, but rather changing base.bbclass (and
> > anything else) to not blow up if OVERRIDES contains duplicates.  I think
> > it's possible to add a python function that does it, but it would have
> > to be 'slow' since the fast method is to throw everything into a dict
> > and then return the list of keys.  So perhaps it's best to just say
> > libc-<foo>  for an additional per-libc override.
> 
> libc-<foo> is also a lot clearer in the case of newlib :)

Playing with OVERRIDES can get messy quickly. The key to success is
having patterns which are unique. "glibc" is therefore not as good as
"libc-glibc". This is why there are the "task-" and "pn-" namespaces and
IMO, namespaces are essential there.

Yes, there are several things we add there without namespacing but we've
mostly been lucky...

Cheers,

Richard