[oe] [RFC] Bring PREFERRED_LIBC to all distros

[Graeme Gregory]

On 05/11/2009 09:07 AM, Richard Purdie wrote:
> 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...
>
>    
I agree with this reasoning and I also far prefer libc-blah to read as 
well. I think we should go for this form.

G