bug-gnulib
[Top][All Lists]
Advanced

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

Re: warnings.m4: check the compiler, not the preprocessor.


From: Eric Blake
Subject: Re: warnings.m4: check the compiler, not the preprocessor.
Date: Thu, 29 Mar 2012 16:25:12 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120316 Thunderbird/11.0

On 03/29/2012 07:36 AM, Akim Demaille wrote:
> For Bison I would like to test C and C++ warnings
> in two different batches.  Currently the macro does
> not depend on the language to store its result, and
> it does not try to compile, just to preprocess.
> 

> * m4/warnings.m4 (gl_WARN_ADD): Use the compiler, not the
> preprocessor.
> Depend on the current AC_LANG for the cache variables.

Both of these changes make sense, since some warnings are
language-dependent, and the preprocessor can't filter out which language
you meant.

I've pushed your patch after testing that it still picked up compiler
warnings when used with libvirt.

> 
> 
> FWIW I used to use a generic scheme, where I checked the
> stderr of the compiler to see if the option was really
> accepted: in some case (e.g., GCC) the compiler will
> accept the option ($? = 0) yet it will constantly complain
> about its uses.  Is there interest in this approach?

gcc 4.7 appears to have modified things even more - my experience is
that it silently ignores unknown -Woptions if the rest of the program is
warning-free, but the moment you have a warning about bad code, you
_also_ get a warning about the unknown option.

Checking stderr is risky, but if it lets us more accurately filter
things, I'd welcome an additional patch to at least debate whether to
include it.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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