Re: RFC: "Virtual" native and sdk recipes

[Richard Purdie <rpurdie@rpsys.net>]

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?

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. 
* 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.
* 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) :/

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.

Cheers,

Richard