Compiling ports in a post-9.0-RELEASE world

[Matthias Andree]

Am 12.03.2011 23:00, schrieb Doug Barton:
> Howdy,
>
> As many of you are no doubt already aware, much work has been undertaken
> to make clang the default compiler for the src tree starting with
> 9.0-RELEASE. It is not 100% certain that this change will be made, but
> it's looking more likely every day.
>
> This raises an interesting question for how to deal with compiling ports
> after 9.0 is released. So far there are 2 main ideas for how to deal
> with this:
>
> 1. Fix all ports to compile with both gcc 4.2 (for RELENG_[78]) and clang.
> 2. Adopt an official "ports compiler," which would likely be one of the
> gcc versions from the ports tree itself, and update all ports to work
> with it.
>
> Both options have pros and cons, but rather than front-load the
> conversation about them I'd like to throw open the topic for discussion
> and see what people think about these options, and whether someone has a
> better idea.

The question is how many ports will silently assume they're running 
under GCC, and how compatible clang is.

So far I've found clang surprisingly good in that it revealed a few 
quirks in my own software (in C) that GCC or ICC had silently accepted, 
and the static analyzer has a few rough edges, but I have found bugs in 
my own software, not in clang 2.8 so far, although I suspect that a few 
might linger there.

We have USE_GCC, currently often used to use a newer GCC version than 
what is in the base system, and I suppose this feature will remain there 
for a loooong time.

So my proposal is:

3. Stronly prefer (1), fix the ports. If the port can't be made to work 
with clang with reasonable effort, we have a fallback solution and can 
set USE_GCC until the port gets fixed (which the important ones probably 
will).  Add support for USE_GCC=yes to set a sane default, f. i. 4.2+). 
  For simpler upgrades, that makes the port GCC version agnostic but 
still states "clang won't work".

Rationale:

NOT adopting a particular ports compiler is a unique chance to get 
upstream software more portable (on the assumption that the majority of 
portability patches will sooner or later travel and get integrated 
upstream) and possibly get a few bugs resolved.

For C89-style software that I've seen, if it didn't compile with clang, 
the software was buggy, not clang lacking.  I know things may be 
different with corner cases for C99 or C++, and surely some C++0x 
features will require GCC, as will Fortran, Java, and thereabouts.

Best regards

-- 
Matthias Andree
ports committer