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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2011-05-18 at 10:48 +0200, Frans Meulenbroeks wrote:
> 2011/5/18 Richard Purdie <richard.purdie@linuxfoundation.org>
> 
> > On Wed, 2011-05-18 at 00:49 -0700, Khem Raj wrote:
> > > I think we need to globalize libc variable like MACHINE or MULTIMACHINE
> > > and we could check if PREFERRED_PROVIDER_virtual/libc == TCLIBC or not
> > > in base.bbclass for sanity. Something like attached patch might be
> > > able to do it
> >
> > Having assessed how many places in the system we'd need to make this
> > kind of change I'm now of the opinion its too great. I think
> > manipulating TMPDIR is a better cleaner solution and we should inject
> > this there...
> >
> >
> > Note that this introduces  additional build time and space to rebuild
> native recipes for the different TMPDIR variants. Something which is not
> needed with the solution from Khem, if I properly understand things.

I mentioned this elsewhere in the thread but the sstate cache directory
is in TOPDIR, not TMPDIR so its shared between the builds. This means
the -native recipes should not need any additional build time. There is
some disk space usage but this should be minimal and disk space is
comparatively cheap anyway.

> From a conceptual point of view it seems better to mangle the target subdir
> name  in work (e.g. ppce300c3-oe-linux-uclibc) or introduce a subdir in
> TMPDIR for  (e.g. ppce300c3-oe-linux/uclibc )

This turns out to be quite nasty mangling as the deploy directories
don't include this and would need mangling in a certain style, the
sysroots need a different mangling and so does workdir, the cache
directories and so on. What these all have in common is they're in
TMPDIR and the native directories are pretty much the only thing we
don't mangle. The exceptions to the mangling seem to work out quite ugly
as in the cross case we have to "half-mangle" directories too.

> (actually I seem to recall that we have or had something in OE as 
> well, something like deploy/glibc)

Some of it worked ok in OE, some of it didn't and the move to a sysroot
directory per machine was the straw that broke the camel's back so to
speak. We need to take a step back and consider what we're trying to
achieve from an overall architecture perspective and which solution
makes sense.

Cheers,

Richard