ni...@lysator.liu.se (Niels Möller) writes: > 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. Please don't let me be misunderstood, as already the The Animals said. :-)
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 ;-) We could use a short clang whitelist instead of a clang blacklist? Here is a beginning: "" :-) > 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. I am talking of such automatically enabled options (typically triggered by config.guess' CPU name). (I added some more clang testing on bdw.gmplib.org now, using clang 3.5 for many x86-64 CPUs.) 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. Make sense. I am grateful you engage in the automated GMP testing stuff. I really need some offloading there. :-D > 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. I disagree. The challenge is making people find the info and actually read it. Descriptions of failing scenarios tend to be long, with subtle pieces of information which determines the relevance. > 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. I've played with that idea... -- Torbjörn Please encrypt, key id 0xC8601622 _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel