[oe] RFC: "Virtual" native and sdk recipes

[Tom Rini]

On Fri, Jan 09, 2009 at 12:54:50AM +0000, Richard Purdie wrote:
> On Fri, 2009-01-02 at 01:11 +0000, Richard Purdie wrote:
> > I just had a look through the trini/canadian-sdk branch and there are
> > bits I like and bits I dislike. I'll try and provide some feedback in
> > due course with a view to getting the less controversial bits merged. I
> > have some tweaks in poky to do with dynamic library extension handling
> > for example (from playing with darwin targets) where it would pay us to
> > find a common solution.
> 
> Sorry for the delayed feedback, what I've looked at so far follows
> below. It was easiest to extract some patches from your tree and make
> some commits of my own so these are in:
> 
> http://git.openembedded.net/?p=openembedded.git;a=shortlog;h=refs/heads/rpurdie/canadian-sofar
> 
> Basically I wanted to particularly review the changes to the existing OE
> core classes/bitbake.conf. The changes in that branch are versions I'm
> happy with. I had two concerns there:
> 
> 1. I don't want to see ${HOST_EXEEXT} everywhere but I know why you 
>    need it and this was something OE would inevitably face. As a 
>    compromise I propose adding:
> 
>    EXEEXT = "${HOST_EXEEXT}"
> 
>    and using ${EXEEXT} which is fractionally less ugly for all common 
>    uses. Could you update your patch to use ${EXEEXT} please assuming 
>    we all agree on this. Its the same dilemma as the SOLIBS stuff I 
>    have with Darwin :/
> 
> 2. All the bb.data.inherits_class() stuff is ugly as sin and totally 
>    unreadable. My series has a better patch.
> 
> Moving on to the rest of the code, I don't see a problem merging any of
> the totally new files. How about the following merge process:
> 
> a) We push my tree into OE

My git-fu is weak and since we can't delete remote branches without
bugging someone, can we do this step?  I've got...

> b) You rebase onto my tree's changes and adjust the EXEEXT stuff.
> 
> c) You add changes which add the EXEEXT changes only to existing 
>    recipes and commit that.
> 
> d) The checksums.ini changes are a no brainer.
> 
> e) You start adding the totally new files to OE directly in a logical 
>    sequence of something like:
> 
>    i) Add canadian core classes (classes/canadian*)
>    ii) Add mingw new recipes
>    iii) Add misc support recipes (gmp/mprf-canadian)
>    iv) Add new binutils recipes
>    v) Add new gcc recipes

... this done locally, mostly, in quilt.

-- 
Tom Rini