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. EinsteinReceived on Tue Sep 11 2012 - 14:03:13 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:30 UTC