[OE-core] Heads up: xxx-nativesdk -> nativesdk-xxx change

[Khem Raj]

On Aug 25, 2012, at 2:00 PM, Richard Purdie <richard.purdie at linuxfoundation.org> wrote:

> On Sat, 2012-08-25 at 13:25 -0700, Khem Raj wrote:
>> On Sat, Aug 25, 2012 at 9:46 AM, Richard Purdie
>> <richard.purdie at linuxfoundation.org> wrote:
>>> As was previous discussed on the list a while ago, we have a problem
>>> with nativesdk where the code is getting complex and convoluted as its
>>> simply not possible to automatically "extend" using a suffix.
>>> 
>>> Extension using a prefix works comparatively well be comparison as shown
>>> by the multilib code. Its for this reason I'd like to switch the
>>> meta-toolchain nativesdk recipes to become a prefix rather than a
>>> suffix.
>>> 
>>> I'm going to propose some patches soon that do this. The patches are
>>> fairly nasty to write and maintain so will need to merge fairly quickly.
>>> 
>>> If anyone does have a strong objection to this change, now is the time
>>> to raise it. I'd prefer not to have to do this but having considered all
>>> the options, its the best thing to do for the future and will result in
>>> cleaner metadata (look at PKGSUFFIX in eglibc for an example of how
>>> messy this gets).
>> 
>> I think we should then also remove prefixing others too for consistency
>> 
>> its hard enough to get the OE terminology to users for gcc and
>> gcc-cross and gcc-crosssdk and so on and now we are creating an
>> anomaly here. I am ok
>> if call it cross-gcc and crosssdk-gcc and native-gcc and so on. That
>> will make it consistent to prefix everything then
> 
> This is a cost/benefit thing. nativesdk is pretty crippled at the moment
> by this, we can't easily extend it to several recipes without more
> PKGSUFFIX nastiness and it will limit its functionality. We do already
> have precedent with the multilibs.
> 
> On the plus side, nativesdk doesn't feature strongly in most OE user
> experience, the documentation and its not massively engrained in the
> code base.
> 
> Equally, you could change -cross as those recipes are corner cases,
> there are not many of them.
> 
> For native things are *very* different. There is no PACKAGES problem
> there, we actively want to keep the numbers of recipes low, there is a
> higher volume of -native references in the documentation and the
> userbase is exposed to the naming. There are many -native recipes in
> other trees out there. So I'm afraid my view is that -native is simply
> not worth the pain.
> 
> If we make an invasive change, I'm ok with that *if* we have good reason
> for it. We have that with -nativesdk, we don't for -native IMO.
> 

I am experiencing teaching new folks OE tricks and one day they might be OE contributors
and believe me it does not help if we have inconstancies, its hard enough and this doesn't make it easier.

Since multilib is something not of interest it hasn't appeared so strongly in my case however it was easy
to say you extend recipes and by appending to their name its easier to change to prepend but some append
some prepend I don't know personally I know it enough that I can deal with it but for new folks its another
thing to learn.

> Cheers,
> 
> Richard
> 
> 
>