This is probably slightly nicer anyway, in that it specifies exactly
_which_ ANSI standard I'm talking about; but the main reason for
making the change is that it means I can now build the Unix puzzles
with clang.
It's not that clang doesn't _support_ -ansi; it accepts it just fine
on any command line that's actually doing some compiling. But on a
link-only command line, i.e. with only object files as input and no
sources, clang emits the annoying warning "argument unused during
compilation: '-ansi", and if you have -Werror as well then that
warning becomes an error.
You'd think there would be some makefile flags variable I could
nonetheless put -ansi in, but apparently not - automake passes CFLAGS
to both compiles and to link-only commands.
And you'd also think that surely I should be able to work around this
by having my configure.ac do a test link and stop trying to use that
option if it didn't work - especially since configure.ac already tests
a bunch of compile options to make sure they don't object to system
header files, after the time I found that a GTK header was
incompatible with my usual -Werror. But in fact, if I change that
AC_COMPILE_IFELSE to an AC_LINK_IFELSE, autoconf generates a single
compile-and-link command line, and hence does not expose the problem
using -ansi on link-only command lines.
Fortunately, -std=c89 does not generate this same warning from clang.
I don't know why not - surely the two options are more or less
equivalent - but it makes my build work again for the moment.
if test "x$GCC" = "xyes"; then
AC_MSG_CHECKING([for usable gcc warning flags])
gccwarningflags=
- for flag in -Wall -Werror -ansi -pedantic; do
+ for flag in -Wall -Werror -std=c89 -pedantic; do
ac_save_CFLAGS="$CFLAGS"
ac_save_LIBS="$LIBS"
CFLAGS="$CFLAGS$gccwarningflags $flag $GTK_CFLAGS"
~ian / sgt-puzzles.git / commitdiff