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

[Richard Purdie]

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.

Cheers,

Richard