Re: AC_CHECK_FUNCS and gcc with -Werror

[Eric Blake]

According to Steffen Dettmer on 3/3/2010 4:27 PM:
>> # ------------------------------------------------
>> # Adds parameter to WARN_CFLAGS if the compiler supports it.  For example,
>> # gl_WARN_ADD([-Wparentheses]).
>> AC_DEFUN([gl_WARN_ADD],
> 
> (If I understand correctly, this macro checks if the compiler
> still runs when the flag is given.)

Yes.

> 
>> Then in configure.ac, you give the user the option to request extra
>> compiler flags, and create an AC_SUBST variable containing the result of
>> the supported flags:
>>
>> AC_ARG_ENABLE([gcc-warnings],
> 
> ahh, you already wrote but I just notice now, it is gcc-option.
> So instead of --enable-errors we could use --enable-gcc-errors
> and --enable-cl-errors.

GNU m4 named its particular configure option '--enable-gcc-warnings',
because m4's configure.ac only lists options known to belong to gcc
(although those options may also be accepted by non-gcc, in which case
they can still be detected and used).  You are free to use a different
name for your configure; the name --enable-errors works nicely.  In fact,
the whole point of gl_WARN_ADD is that it filters out working options from
a larger list of possible options.  So, by removing the compiler name from
your enable option, and calling:

  gl_WARN_ADD([-Werror], [WERROR_CFLAGS])
  gl_WARN_ADD([-WX], [WERROR_CFLAGS])

you can support both compilers at once.  Or even make it a shell list:

opt=
opt="$opt -Werror"
opt="$opt -WX"
for o in $opt; do
  gl_WARN_ADD([$opt], [WERROR_CFLAGS])
done

so that adding another spelling of some other option that you find useful
becomes a matter of just tweaking $opt.

>> AM_CFLAGS = $(WERROR_CFLAGS)
> 
> ahh ok this way.
> Before I change my 352 Makefile.am's:
> - Can this do harm (e.g. in makefiles for packages without C
>   sources or so)?

What harm are you envisioning?  It is harmless to set AM_CFLAGS in a
Makefile.am that has no C source files, but it only has an effect when
compiling C code.

> - Can I simply append `AM_CFLAGS += $(WERROR_CFLAGS)' to each
>   Makefile.am and be done?

Probably, as long as something earlier in the file already set AM_CFLAGS.
 You can even make all of your Makefile.am include a common makefile
fragment, and do the WERROR_CFLAGS manipulation only once in that common
fragment.

> - should I better use something like `-include warnings.mak' or
>   alike to be more flexible in case I'll need it later?

Yep - that's what I was saying in the line above before I ready your question.

> 
> - Alternatively, by accident, ts there some way to tell configure
>   something like: right just before writing config.status, set
>   `CFLAGS=$CFLAGS\ $WERROR_CFLAGS' or so?
>   As Peter suggests?

Perhaps; AC_CONFIG_COMMANDS_PRE probably fits the bill as the ideal macro
to use for guaranteeing that you inject your shell code at the last
possible moment.  I'm not sure of the ramifications of setting CFLAGS like
that, though, if the user passed in an explicit CFLAGS when they invoked
configure (if CFLAGS started life uninitialized, you are free to set it to
anything, but per GNU Coding Standards, if CFLAGS was explicitly set, you
shouldn't modify it, on the assumption that the user knows best).  That's
why I recommend changing AM_CFLAGS, not CFLAGS.

> - Instead of changing 352 Makefile.am's, should I change 42
>   configure.{in,ac} to have a line like
>   CFLAGS=$CFLAGS\ $WERROR_CFLAGS
>   right before AC_OUTPUT?

That's the same question you asked above.  AC_OUTPUT _is_ the point where
config.status is written.

>>> We now have in configure.in (or actually an included .m4
>>> file) `CFLAGS="$CFLAGS -Werror";'
>>
>> That's where you are going wrong.  The recommended approach is
>> to modify CFLAGS in the Makefile, using an AC_SUBST, rather
>> than hard-coding the modification into configure.
> 
> ohh I though configure should configure the compiler flags?

Yes it should, and that's what this whole thread has been about.  But in
the case of -Werror, you want to configure the flag to only be in effect
at make time, and not impact the flags to be used for the remainder of the
configure run.  In other words, it is imperative that what configure
learned about -Werror be delayed until make time, rather than being
applied immediately.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature