ni...@lysator.liu.se (Niels Möller) writes: I think that requiring an --enable-clang to be able to build with any version of clang on any platform whatsoever is a bit harsh.
Harsh against whom? The point is not to make a statement, but to make it more likely that GMP works correctly for our users. On the other hand, a blacklisting of known broken compilers (by version and where relevant also by platform), and a --disable-compiler-blacklist option to override it, would be helpful to both users and us. This would be great, but it is a significant burden to maintain. And, let's say that clang 3.4 works for compiling GMP on x86-64 except when passed -mtune=foo and -mtune=bar. Blacklisted or not? I suggest that this is the situation for x86. Of course, we may define any granularity here, with corresponding maintenance cost. If a user has the latest and greatest clang on a very vanilla x86 system where it actually works fine, the user is going to be pretty annoyed by an --enable-clang option, and possibly make it a habit to always use that option. I suppose I need to make my point clearer by enabling broader clang testing; I doubt there exist a clang release which does not miscompile GMP for some -mtune= option... Ideally, the blacklist in configure should automatically turn red entries to orange on the list of test results. And unexpected successes with a blacklisted compiler could also be marked in some happy color distinct from the usual green. The former is perhaps not so easy, the latter is simple. Light green...? It would also be useful to have an overview of known compiler issues somewhere on the web-page, and a pointer to that info in the bug-reporting chapter in the manual. A bit like the freebsd problems listed in recent NEWS. I think this has limited value. It will also tend to become a list of obsolete issues, unless we remember to maintain it. We need to keep in mind that of the users that compile GMP from source, very few will do anything but "configure; make; sudo make install". How often do you yourself scan a manual for build problems before building a package? :-) > BTW, it would be nice with an alternative test result page with > problematic platforms only, or sorted with failing platforms at the top. > > Not sure what you mean. Just problematic confs, with the problematic > confs on top? Or do you mean to put clang test results on a separate > page? Either some way to sort the current list so that builds with problems are at the top, followed by the all-green entries. Or a separate page, where the all-green entries are omitted. With the current list, quite a lot of scrolling is needed to identify the set of failed builds. I'll see what I can do... -- Torbjörn Please encrypt, key id 0xC8601622 _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel