Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD

On Mon, 31 May 2010, Robert Watson wrote:
>
> I think Kostik's question here is legitimate: clang maturity changes over 
> time.  The earlier we adopt it, the sooner we get the advantages of clang -- 
> but we also end up being the people who fault in more of the hard-to-diagnose 
> compiler bugs.  Since Kostik fields many of our complex file system/VM/etc 
> bugs, which are themselves often symptoms of hardware problems rather than 
> software bugs (a similar class of issue), and is on the release engineering 
> team, I think he speaks with some authority on the matter.
>
> I happen to (currently) disagree with him on whether clang is ready for us to 
> drop in the base system, as I feel providing early access to it (but not 
> enabling it as the bootstrap by default) will be of significant benefit, but 
> don't think that delegitimizes the concern he raises.  You can burn a lot of 
> hours chasing software bugs only to eventually (or never) figure out they are 
> compiler bugs.
>
> This is the trade-off, but as you point out in your e-mail, there is also a 
> larger non-technical context.  By throwing our weight behind clang, we 
> benefit in numerous and often non-technical ways: we lend the clang folks an 
> engaged and technically astute user community who can help them mature their 
> software, as well as give them a user they community they can point at as 
> part of establishing their own legitimacy.  That engagement in turn means 
> they will be more responsive to our needs, and it's clear we're at a swing of 
> the compiler/systems pendulum where we can benefit from the improved compiler 
> technology we get through using clang.

I would like to see this decision made without political bias.

Is clangBSD able to support all our architectures?  Does it
cross build for powerpc, mips, etc?  Has it made a ports run
and does it successfully build and run most of our ports on
Tier-1 archs, and does it compare similarly with gcc for ports
on other archs?

If it is clearly in a state to entirely replace gcc, then
I say import it.  But if it is not yet there, and won't be
for some time, then I would say leave it out for the time
and import it when it can.

-- 
DE