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

[Tom Rini]

On Tue, Jan 13, 2009 at 06:15:39PM -0700, Tom Rini wrote:
> 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.

Making more noise as I'm thinking on Friday I'll just merge RP's branch
to mainline.

-- 
Tom Rini