Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 11 Sep 2012 08:56:21 -0700
From:      Garrett Cooper <yanegomi@gmail.com>
To:        Daniel Eischen <deischen@freebsd.org>
Cc:        toolchain@freebsd.org, current@freebsd.org
Subject:   Re: Clang as default compiler November 4th
Message-ID:  <CDE88355-8F5A-4803-AF37-C7D10D1F7146@gmail.com>
In-Reply-To: <Pine.GSO.4.64.1209111131500.21183@sea.ntplx.net>
References:  <20120910211207.GC64920@lor.one-eyed-alien.net> <20120911104518.GF37286@deviant.kiev.zoral.com.ua> <20120911120649.GA52235@freebsd.org> <20120911122122.GJ37286@deviant.kiev.zoral.com.ua> <Pine.GSO.4.64.1209111131500.21183@sea.ntplx.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sep 11, 2012, at 8:35 AM, Daniel Eischen wrote:

> On Tue, 11 Sep 2012, Konstantin Belousov wrote:
>=20
>> On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote:
>>>=20
>>> 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.
>>=20
>> 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.
>=20
> [ snip ]
>=20
>>> 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.
>>=20
>> 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.
>=20
> 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=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CDE88355-8F5A-4803-AF37-C7D10D1F7146>