t...@gmplib.org (Torbjörn Granlund) writes: > 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.
It's going to look very much like you're making a statement, whether or not that's your intention. > 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. Assuming the blacklisting assumes that unknown newer versions are working, it's sufficient to update it whenever a new broken compiler or a new broken version gets widely used. And a general blacklisting of clang will also need regular reconsideration. I'd expect that there's going to be a clang version x in the not too distant future which is able to compile gmp correctly at least on x86_64. But I'm not going to place any bets on it ;-) > 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? Blacklist it if and only if those options are ever enabled automatically by gmp's configure. > 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. Assuming there's some blacklisting logic is in configure, and that our test machines always configure using the blacklist-override option, one could let the configure summary output a line saying that the platform+compiler has known problems and is expected to fail. Then check for that line when selecting the color. > Light green...? Sounds good enough. > I think this has limited value. It will also tend to become a list of > obsolete issues, unless we remember to maintain it. It needs to be updated whenever new issues worth documenting arrives. There's no harm in historical data. > 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". Then maybe we chould have the default make target depend on check... So those pesky users have to type make i-really-really-want-to-skip-testing to build the library without testing it. > How often do you yourself scan a manual for build problems before > building a package? :-) Before? Never. But if make or make check fails, I'll probably do a web search on the package name and error message. And when all else fails, I'd be tempted to refer to the fine documentation. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel