Date: Tue, 11 Sep 2012 17:03:09 +0100 From: Attilio Rao <attilio@freebsd.org> To: Garrett Cooper <yanegomi@gmail.com> Cc: Daniel Eischen <deischen@freebsd.org>, current@freebsd.org, toolchain@freebsd.org Subject: Re: Clang as default compiler November 4th Message-ID: <CAJ-FndDaG3n=tO6nmYu21S0WpWirCijvL3iCF24aXNqmKXnp%2Bg@mail.gmail.com> In-Reply-To: <CDE88355-8F5A-4803-AF37-C7D10D1F7146@gmail.com> 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> <CDE88355-8F5A-4803-AF37-C7D10D1F7146@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Sep 11, 2012 at 4:56 PM, Garrett Cooper <yanegomi@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 maintai= ner >>>> never saw them being broken with clang just because it's not the defau= lt >>>> 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 L= inux, Gentoo Linux, etc, so encouraging external developers to correct/simp= lify their Makefiles and build infrastructures is a good thing (and plus, i= t 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/Li= nux should not strive to get others to hardcode less. > > I wouldn't consider ports to be a stopgap for the clang switchover as muc= h as correctness/performance. Broken third-party software can be fixed, but= if the underlying foundation doesn't deliver sane code or severely regress= es performance (runtime is more important than building IMO because I'd rat= her 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@ 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 --=20 Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-FndDaG3n=tO6nmYu21S0WpWirCijvL3iCF24aXNqmKXnp%2Bg>