[OE-core] [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes

[Richard Purdie]

On Tue, 2011-05-17 at 10:17 +0100, Phil Blundell wrote:
> On Tue, 2011-05-17 at 01:13 +0100, Richard Purdie wrote:
> > The more I looked at that patch, the more holes I could see in what we
> > were doing (and what Angstrom currently does). I started playing around
> > with the patch below which tried to improve on that idea.
> > 
> > I then concluded that we might be able to do something like:
> > 
> > MACHINEOVERRIDES := "${MACHINE}"
> > MACHINE_append = "-uclibc"
> > 
> > since what we're really trying to do in the uclibc case is replace
> > anything MACHINE specific with something containing uclibc?
> 
> I think that particular change would be a bad idea for several reasons.
> Firstly, and perhaps most importantly, MACHINE is a primary
> configuration variable and having it magically change under the hood
> seems like it would violate the principle of least surprise.  Secondly,
> at a practical level, this would make it hard to use MACHINE for
> anything other than overrides.  And thirdly, at a conceptual level, the
> choice of libc is really nothing to do with the MACHINE.
> 
> > diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
> > index 553c6a2..354668f 100644
> > --- a/meta/classes/sstate.bbclass
> > +++ b/meta/classes/sstate.bbclass
> 
> This patch looks good to me (and I would definitely prefer this to the
> solution above).  The lines that you have deleted from tclibc-uclibc.inc
> were causing my uclibc builds to fail so I would certainly be glad to
> have them removed.

No question those lines are "wrong" but the solutions various people are
using out there are "wrong" in various ways too (including what is
'working' in ansgtrom at the moment).

A solution where you replace 80% of uses of a variable with a new
variable as per my proposed patch doesn't quite feel right either.

How about this idea:

TMPDIR_append = "-uclibc"

since sstate cache is deliberately outside TMPDIR so anything that can
be reused between builds will automatically.

Simple, effective and addresses a lot of the bugs I can see in the other
approaches...

Cheers,

Richard