Re: Clang as default compiler November 4th

On Tue, Sep 11, 2012 at 4:56 PM, Garrett Cooper <yanegomi_at_gmail.com> wrote:
> 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.

While this is generally true I think we need to make a distinction. To
me speaking about "not compiling ports" doesn't mean anything. What
are the bugs that actually prevents the vast majority of ports from
compiling? (speaking of which anyone has testing their actual
functionality too?) Because I really don't expect the bugs to be
always the same repeated over and over, there will be some bugs
depending by brain-o in the ports code and other depending by clang
bugs. As kib_at_ rightly points out fixing indiscriminately ports is not
the solution, but fixing ports when *the bug is actually in the port
itself* is the right solution, otherwise fix the compiler for the
other class of bugs.

Did the people pushing for default clang make an assessment on the
type of ports bug present? (and I see there is a lot of people aiming
for it, so if the ports are splitted among several people we can get a
good handle on it). Could such bugs be characterized and classified?

Making such a huge change is also a matter of loosing much time on
problems which don't seem directly related to it, but which infact
prevent the system from working correctly. Switching to default CLANG
with the current situation (20% of port not even compiling, ports
compiler selection broken, libm loss of precision, performance barely
analyzed in simplified scheme, etc.) is not an option in my head and
people should really reconsider it, unless all these points gets
properly addressed.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein