> 1. gcc will still be available through the ports system.
As well as clang is available in ports. not an argument.
> 2. The move to clang/llvm as a default compiler will reduce the amount
> of GPL code in the base system, eventually reducing distribution
> issues (especially for 3rd parties).
true. But JUST reducing GPL code should be a target per se.
FreeBSD is about performance and quality not politics or religion.
We don't want GPL code because it prevents doing binary only distributions
and closed source derivatives, which means reducing FREEDOM.
But - if you do closed source derivatives you don't need to include C
compiler to run it. And you may allow C compiler separately with source
included. No problem.
> 3. clang/llvm provides better error and warning messages, as well as
> good static code analysis, which helps reduce some classes of bugs and
> eventually will result in a more reliable FreeBSD system.
as with 1 - you may use clang when developing.
> 4. clang/llvm is improving quickly.
When/If it WILL actually improve to be better than gcc it should be
imported to FreeBSD. not sooner.
> 5. clang/llvm is more modular than gcc, although there are plans for
> gcc to become as modular, it will take time.
Doesn't matter how it is written, but how it performs.
> 6. gcc produces faster code, but clang/llvm will eventually (soon
> enough) get there.
This is your prediction. Not definite fact, mine and other predictions are
> 7. From the reasons above, it makes sense to complete a task sooner
> rather than later, especially that clang/llvm isn't showing any signs
> of weakness (lack of development power, etc).
NOBODY prevent you and FreeBSD developers to fix things already - so
FreeBSD and ports would compile with both compilers.
Actually it is good to fix it already, as making programs compile with
both means usually fixing non-portability bug which would help using third
compiler that may possibly emerge.
But this DO NOT require clang to be a part of main system. As well as
making it default.
> 8. There might be more reasons for or against, but I couldn't think of any.
All "for" arguments assumes clang WILL be better. This is a change as
less than 2 days before it was stated to already be better.
As a comparision - DragonFly BSD is stated to have better ideas that would
result in better performing system in a future.
But FOR NOW it is much worse performer than FreeBSD that's why i (and lots
of other people) does not switch to DragonFly but of course will when(and
if) DragonFly BSD will actually be better. And i don't really think this
"IF" will happen at all, but i wish to DragonFly BSD i am wrong.
Same should be used for clang. AS LONG as it is not better it should not
be imported into base system or worse - used as default.
Making decision based on wishes and personal likes instead of technical
facts isn't something that anyone should be proud about.
As for your words about doing decision good for FreeBSD, not me - it is
pure nonsense attacks because anything that is good for FreeBSD quality is
good for me, and the reverse.
The decision of switching to clang now it shows that ideologic and
"religious" arguments won over technical arguments.
The agressive and data-manipulationg reactions of many people on that list
shows that above sentence is true.