[oe] RFC: "Virtual" native and sdk recipes
Tom Rini
trini at kernel.crashing.org
Sat Jan 17 02:54:34 UTC 2009
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
More information about the Openembedded-devel
mailing list