Re: RFC: "Virtual" native and sdk recipes

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

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