On Wed, 2011-05-18 at 10:48 +0200, Frans Meulenbroeks wrote: > 2011/5/18 Richard Purdie <richard.pur...@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 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
