Re: Clang as default compiler November 4th

On Sep 11, 2012, at 8:35 AM, Daniel Eischen wrote:

> On Tue, 11 Sep 2012, Konstantin Belousov wrote:
> 
>> On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote:
>>> 
>>> We currently dont compile 4680 ports (out of 23857). Top 10 ports that prevent
>>> the most other ports from compiling together prevent 2222 ports from
>>> compilation. So if we fixed those 10 ports we could be at around 2500 ports
>>> not compiling. Thats quite far from your claim of forking 20k programs.
>> 
>> Sorry, I cannot buy the argument. How many patches there are already
>> in the ports tree to cope with clang incompatibility with gcc ? You may
>> declare that all of them are application bugs, but it completely misses
>> the point.
> 
> [ snip ]
> 
>>> I believe majority of the broken ports is broken because their maintainer
>>> never saw them being broken with clang just because it's not the default
>>> compiler. Thus by making it the default majority of the problems would just
>>> go away.
>> 
>> Can you, please, read what I wrote ? Fixing _ports_ to compile with
>> clang is plain wrong. Upstream developers use gcc almost always for
>> development and testing. Establishing another constant cost on the
>> porting work puts burden on the ports submitters, maintainers and even
>> ports users.
> 
> This is a good point!

Alternate compilers are being used on other OS distributions, like Arch Linux, Gentoo Linux, etc, so encouraging external developers to correct/simplify their Makefiles and build infrastructures is a good thing (and plus, it makes switching to other compilers like icc, pcc, etc easier).

You're going to run into almost the same problem when trying to get stuff to cross-compile for multiple targets, so there's no reason why FreeBSD/Linux should not strive to get others to hardcode less.

I wouldn't consider ports to be a stopgap for the clang switchover as much as correctness/performance. Broken third-party software can be fixed, but if the underlying foundation doesn't deliver sane code or severely regresses performance (runtime is more important than building IMO because I'd rather have code take a little while longer to compile if the end-result runs faster, and ultimately runtime performance affects build performance), then there's no point in trying to switch over yet.

Thanks,
-Garrett