[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
encapsulating --enable-gcc-warnings [Re: [PATCH] build: work with new gl
encapsulating --enable-gcc-warnings [Re: [PATCH] build: work with new glibc when not optimizing
Sun, 02 Sep 2012 09:54:56 +0200
This started with a useful coreutils patch by Eric,
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:
[turn on lots of GCC warnings (for developers)])],
[case $enableval in
*) AC_MSG_ERROR([bad value $enableval for gcc-warnings option]) ;;
if test "$gl_gcc_warnings" = yes; then
# 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
nw="$nw -Wc++-compat" # We don't care about C++ compilers
nw="$nw -Wundef" # Warns on '#if GNULIB_FOO' etc in
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):
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]
||[Next in Thread]|
- encapsulating --enable-gcc-warnings [Re: [PATCH] build: work with new glibc when not optimizing,
Jim Meyering <=