Heads up: xxx-nativesdk -> nativesdk-xxx change

Heads up: xxx-nativesdk -> nativesdk-xxx change

[Richard Purdie]

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).

Note that -native are unchanged and there is no problem or planned
change which them, this just affects nativesdk.

An example WIP patch is:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t1&id=2aa1acf11dd26bc194668be81544d08ab5e9bb24

Cheers,

Richard

Re: Heads up: xxx-nativesdk -> nativesdk-xxx change

[Khem Raj]

On Sat, Aug 25, 2012 at 9:46 AM, Richard Purdie
<richard.purdie@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

>
> Note that -native are unchanged and there is no problem or planned
> change which them, this just affects nativesdk.
>
> An example WIP patch is:
> http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t1&id=2aa1acf11dd26bc194668be81544d08ab5e9bb24
>
> Cheers,
>
> Richard
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: Heads up: xxx-nativesdk -> nativesdk-xxx change

[Chris Larson]

On Sat, Aug 25, 2012 at 1:25 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Sat, Aug 25, 2012 at 9:46 AM, Richard Purdie
> <richard.purdie@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

I agree, I think it'd be nice to just bite the bullet and change them
all, if we can manage it.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: 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@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

Re: Heads up: xxx-nativesdk -> nativesdk-xxx change

[Khem Raj]

On Aug 25, 2012, at 2:00 PM, Richard Purdie <richard.purdie@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@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
> 
> 
> 

Re: Heads up: xxx-nativesdk -> nativesdk-xxx change

[Richard Purdie]

On Sat, 2012-08-25 at 14:14 -0700, Khem Raj wrote:
> On Aug 25, 2012, at 2:00 PM, Richard Purdie <richard.purdie@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@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.

I might also have some experience of showing people the system ;-).

Whilst I understand the point, I think there are other areas that time
could be spent that would benefit people more than the naming of the
native recipes.

The native recipe change would be extremely invasive and effectively
require a flag day where everyone changes every layer. We lose our
compatibility and layer interoperability story and we cause a big
headache for anyone working with this from a commercial perspective too.

Its ok to require some changes for the right reasons but do this too
often or for the wrong reasons and we'll seriously upset users and
suffer as a project as a result. Its very easy to decide to make some
change to "improve" things but the implications need to be thought
through and accounted for.

FWIW, I think we did a bad job with the gcc-intermediate change. In
hindsight I think we should have changed the gcc-cross-initial include
name in master, allowing backwards compatibility. The intermediate
include could have then been moved to the toolchain layer, removing the
need for a flag day for every eglibc/gcc out there. I'm saying this not
to pick on anyone, I'm as guilty as anyone for merging the change. I do
want to illustrate we're thinking about the issues people hit and how to
better in future though.

Cheers,

Richard