Re: RFC: "Virtual" native and sdk recipes

[Tom Rini <trini@kernel.crashing.org>]

On Wed, Jan 14, 2009 at 04:17:05PM -0700, Tom Rini wrote:
> 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.

I'm fairly certian my git-fu did not fail and this has been done.  I'll
make branch of e-i -> e-v soon I hope (painting in the new house this
weekend).

-- 
Tom Rini