[oe] RFC: "Virtual" native and sdk recipes
Tom Rini
trini at kernel.crashing.org
Fri Jan 9 01:16:03 UTC 2009
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
>
> 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
>
> f) You make a diff of the remaining changes that are needed and we
> review those.
>
> Hopefully this reduces the overhead of the branch, lets you make
> progress and then helps us review the remaining code.
>
> Does that seam reasonable?
Sounds good. I'll see what I can do about finding somewhere to sit
while borrowing someones wifi at my new place and hopefully get
something going tomorrow.
> Things I've noticed in the rest of the patches are:
>
> * The amount of code duplication in meta-toolchain/canadian-sdk - we
> really need to think about refactoring that code.
Yes. And for other purposes I'd like a few more hooks for the including
bb file. The one OpenMoko pushed (or is trying to push? haven't looked)
is a good starting place.
> * I'm also not keen on the SDK_PREFIX -> SDK_PATH change. Why? It
> breaks things for people. In fact please back this out before merging
> anything above, I don't see a good reason for it.
Esben?
> * The choice of OVERRIDE you're using worries me as sdk- is far to much
> of a generic expression. You don't use the overrides much and only
> for DEFAULT_PREFERENCE. Can we not find a better way to do this and
> avoid adding overrides? The fact these are there suggests something
> with the PROVIDES and DEPENDS logic you're using is broken as it
> should be fairly magic (and a lot of effort went into that for the
> standard toolchains) :/
I'll see what I can do about removing that, then.
> Also, this is all on the understanding I've previously mentioned that we
> will need to rewrite and break this stuff at some point sooner or later.
Right.
--
Tom Rini
More information about the Openembedded-devel
mailing list