[oe] RFC: "Virtual" native and sdk recipes
Richard Purdie
rpurdie at rpsys.net
Fri Jan 9 00:54:50 UTC 2009
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
More information about the Openembedded-devel
mailing list