[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
encapsulating --enable-gcc-warnings [Re: [PATCH] build: work with new gl
From: |
Jim Meyering |
Subject: |
encapsulating --enable-gcc-warnings [Re: [PATCH] build: work with new glibc when not optimizing |
Date: |
Sun, 02 Sep 2012 09:54:56 +0200 |
[cc'ing bug-gnulib]
This started with a useful coreutils patch by Eric,
http://thread.gmane.org/gmane.comp.gnu.coreutils.general/3164
The thing is, it belongs in nearly every project that
also provides the configure-time --enable-gcc-warnings option:
Mike Frysinger wrote:
> On Sat, Sep 1, 2012 at 12:10 PM, Eric Blake wrote:
>> Starting with glibc 2.15, the system headers refuse to compile
>> unconditional use of FORTIFY_SOURCE if optimization is disabled
>> but -Werror is in effect.
>
> pretty sure you mean 2.16.0
>
>> Pushing, as this is similar to the recent coreutils patch.
>
> too little code for a gnulib module ? and i guess GNU projects don't
> want to rely on the autoconf-archive (AX_*) ?
I thought the same thing, and wanted to make it the default, somehow,
i.e., piggy-back on another nearly-always-used gnulib module.
However, that added code is in a conditional:
AC_ARG_ENABLE([gcc-warnings],
[AS_HELP_STRING([--enable-gcc-warnings],
[turn on lots of GCC warnings (for developers)])],
[case $enableval in
yes|no) ;;
*) AC_MSG_ERROR([bad value $enableval for gcc-warnings option]) ;;
esac
gl_gcc_warnings=$enableval],
[gl_gcc_warnings=no]
)
if test "$gl_gcc_warnings" = yes; then
gl_WARN_ADD([-Werror], [WERROR_CFLAGS])
AC_SUBST([WERROR_CFLAGS])
nw=
# This, $nw, is the list of warnings we disable.
nw="$nw -Wdeclaration-after-statement" # too useful to forbid
nw="$nw -Waggregate-return" # anachronistic
nw="$nw -Wlong-long" # C90 is anachronistic
(lib/gethrxtime.h)
nw="$nw -Wc++-compat" # We don't care about C++ compilers
nw="$nw -Wundef" # Warns on '#if GNULIB_FOO' etc in
gnulib
nw="$nw -Wtraditional" # Warns on #elif which we use often
nw="$nw -Wcast-qual" # Too many warnings for now
...
and the list of -W options we disable varies from project to project.
On the other hand, many projects have a block very similar to this one,
so one possibility is to factor out this configure-time
--enable-gcc-warnings option and its code, including Eric's latest addition.
If someone wants to create a new module that is configurable enough
to be used by these packages (the ones I have handy, and for which
"grep -l enable-gcc-warning" declared a match):
bison
coreutils
cppi
diffutils
emacs
gnutls
grep
gsasl
gss
gzip
hivex
idutils
iwhd
libguestfs
parted
patch
shishi
zile
that would be some serious factoring. In coreutils, that code
occupies more than 100 lines of configure.ac.
The more we can move out of individual package configure.ac files
and into gnulib, where we can centralize improvements, the better.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- encapsulating --enable-gcc-warnings [Re: [PATCH] build: work with new glibc when not optimizing,
Jim Meyering <=