Hi Ben, Vincent, * Ben Pfaff wrote on Wed, Aug 31, 2005 at 04:57:36PM CEST: > > AC_COMPILE_IFELSE generates a test that only checks the exit status > of the compiler command. But this is not sufficient: *snip* > demon ~ % cc -DFOO tst.c && echo OK > cc-1035 cc: WARNING File = tst.c, Line = 2 > #error directive: "FOO is defined" > > # error "FOO is defined" > ^ > > OK > demon ~ % > > An a.out program is generated. I'm not sure whether this is conforming > to the C standard, which says: > > [#4] The implementation shall not successfully translate a > preprocessing translation unit containing a #error > preprocessing directive unless it is part of a group skipped > by conditional inclusion. FWIW, I don't think this is conforming (but I've been wrong on C standard issues before, so don't count on that). OTOH, if all software would conform to standards, Autoconf would be a lot less necessary, wouldn't it? :) > i.e. could the implementation decide that the translation is not > successful because of the above warning? Anyway, one of the goals > of the configure script is to detect when things are wrong on the > current platform. So, I think that autoconf should cope with this > problem. Somewhat similar issues have come up a couple of times recently: http://lists.gnu.org/archive/html/autoconf/2005-07/msg00083.html http://lists.gnu.org/archive/html/autoconf/2005-07/msg00009.html One possible solution would be an adaptation of Libtool's boilerplate code[1] that looks for differing compiler output, to not only test different compiler switches, but also allow differing input source. I haven't gotten around to implementing an Autoconf version of it yet; the semantics for general use are a bit tricky, IMHO. I would not mind if someone else did it, either[2]. Even when that is done, I would very much hesitate to use it within AC_COMPILE_IFELSE: many compilers routinely output information that varies greatly with the given code, even when the differences are not in warnings. For example, compilers that output every function name, or whether a loop was unrolled. Given this kind of output, it's virtually impossible to predict differences in warnings. Maybe for a subclass of these issues it would suffice to filter out lines with some keywords in them, like "warning", "error", with differing case. Still sounds like a very hacky and ad-hoc solution, and would not be without false positives either, see e.g. [3]. Cheers, Ralf [1] mentioned in this thread: http://lists.gnu.org/archive/html/autoconf/2005-06/msg00001.html http://lists.gnu.org/archive/html/autoconf/2005-05/msg00108.html (see libtool-1.5.20/libtool.m4:AC_LIBTOOL_COMPILER_OPTION and _LT_COMPILER_BOILERPLATE for the code used within Libtool) [2] Note, that there is also a bug in the current implementation: it needs to weed out at least some "set -x" related shell debug output, else running a configure script like this will cause Heisen-antibugs. [3] http://lists.gnu.org/archive/html/libtool/2005-06/msg00110.html _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
