On 9/8/12 3:05 AM, Khem Raj wrote:
On (07/09/12 18:15), Phil Blundell wrote:
On Fri, 2012-09-07 at 18:09 +0100, Richard Purdie wrote:
The key places people get bitten are eglibc and gcc so those should be
straight forward to test, the question is how widely to deploy this
initially. I think the mechanism is good, its now just a question of the
implementation detail.
Eglibc and gcc, at least, support building with ${B} != ${S} so it might
be easier/quicker to just blow away the whole ${B} tree rather than
trying to distclean it.
yeah and I think separating B from S in general has merits in long run
In principal I agree completely, however in practice at least 20-30% of the
packages I try won't deal w/ the B/S separation properly.
A good optimization is likely when B != S, blow away B and start over... if they
are the same, the distclean is likely the best approach..
I imagine that most modern-ish autotools-based packages will also build
fine in that configuration, though there are bound to be some that
don't. It's hard to say whether there are likely to be more or fewer of
those than there are ones where "make distclean" fails.
either way there seems to be same amount of uncertainity.
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
