[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Andrey Simonenko
Subject: Re: Improved AC_LANG_WERROR
Date: Fri, 13 Apr 2007 11:21:10 +0300
User-agent: Mutt/1.5.14 (2007-02-12)

On Wed, Apr 11, 2007 at 06:54:32PM -0700, Paul Eggert wrote:
> Andrey Simonenko <address@hidden> writes:
> > What do you think about the following backward compatible changes
> > (read updated info for the details)?
> I don't see any way with that proposal to temporarily change werror,
> then restore it to its previous value.

Updated version of AC_LANG_WERROR has stack of settings for each language,
and has `pop' argument, which restores settings for the current language
from the top of the corresponding stack:

AC_LANG_WERROR([on])    # c_werror=yes          C stack:
AC_LANG_WERROR([off])   # c_werror=             C stack: on
AC_LANG_WERROR([off])   # c_werror=             C stack: off on
AC_LANG_WERROR([on])    # cxx_werror=yes        C++ stack:
AC_LANG_WERROR([on])    # cxx_werror=yes        C++ stack: on
AC_LANG_WERROR([pop])   # c_werror=             C stack: on
AC_LANG_WERROR([pop])   # c_werror=yes          C stack:

> > I removed m4_divert_text([DEFAULTS], [ac_[]_AC_LANG_ABBREV[]_werror_flag=])
> >>From AC_LANG_WERROR.  Is it really needed?
> I think so; otherwise the value would be inherited from the environment.

What is the better place for:

1. initialization of ac_X_werror_flag variables for all languages
   (which say how to treat warnings).
2. initialization of m4 _AC_LANG_X_WERROR_FLAG macro variables for
   all languages (which are used for building stacks of settings).

All these variables should be initialized only once and for each
language.  Right now this is not implemented, so single two calls:


will fail with:

error: AC_LANG_WERROR: unbalanced number of `on/off' and `pop' calls

> Also, for changes like this it's better to propose a full patch,
> with ChangeLog entry, and send it to autoconf-patches.

AC_LANG_WERROR was rewritten, that's why I decided to not post diff.


# -----------------------
# How to treat warnings from the current language's preprocessor, compiler,
# and linker (works in a stack-like fashion):
# 1. No arguments:
#       Similarly to AC_LANG_WERROR([on])
# 2. One argument:
#       on  -- treat warnings as fatal errors + remember previous value;
#       off -- do not treat warnings as fatal errors + remember previous value;
#       pop -- restore previous value.
    $#, 1, [m4_if(
        [$1], [on], [
            m4_pushdef(_AC_LANG_[]_AC_LANG_ABBREV[]_WERROR_FLAG, [on])
        [$1], [off], [
            m4_pushdef(_AC_LANG_[]_AC_LANG_ABBREV[]_WERROR_FLAG, [off])
        [$1], [pop], [
            m4_ifdef(_AC_LANG_[]_AC_LANG_ABBREV[]_WERROR_FLAG, [],
                [m4_fatal([$0: unbalanced number of `on/off' and `pop' calls])])
                m4_defn(_AC_LANG_[]_AC_LANG_ABBREV[]_WERROR_FLAG), [on],
                m4_defn(_AC_LANG_[]_AC_LANG_ABBREV[]_WERROR_FLAG), [off],
                [m4_fatal([$0: stack of values is damaged])])],
        [m4_fatal([$0: wrong argument: `$1'])])],
    $#, 0, [AC_LANG_WERROR([on])],
    [m4_fatal([$0: incorrect number of arguments: $#])])


@defmac AC_LANG_WERROR (@ovar{value})
Normally Autoconf ignores warnings generated by the compiler, linker, and
preprocessor.  This macro allows to change this behaviour in a stack-like
fashion.  If @var{value} is @code{on} or if an optional argument is not
given, then warnings are treated as fatal errors for the current language.
If @var{value} is @code{off}, then the normal Autoconf's behaviour for
the current language is restored.  Each macro call with @code{on} or
@code{off} value remembers current settings on a stack and sets new
settings for the current language.  Each language has own stack that
is used exclusively by this macro for saving and restoring settings.
If @var{value} is @code{pop}, then settings, that are saved on the top
of the stack, are restored and are removed from the stack.

This macro is useful when the results of configuration are used where
warnings are unacceptable; for instance, if parts of a program are built
with the @acronym{GCC}
option.  If the whole program is built using @option{-Werror} it is
often simpler to put @option{-Werror} in the compiler flags (@code{CFLAGS},
@end defmac

reply via email to

[Prev in Thread] Current Thread [Next in Thread]