[Top][All Lists]

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

Re: Add new macro gl_WARN_ADD_MULTIPLE

From: Tim Rühsen
Subject: Re: Add new macro gl_WARN_ADD_MULTIPLE
Date: Thu, 2 May 2019 21:38:01 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

Hi Bruno,

On 02.05.19 21:12, Bruno Haible wrote:
>>> Does this implementation of manywarnings support only the case where
>>> you want all possible warnings except an explicitly specified set?
>>> Or also the case where you want only an explicitly specified set of
>>> warnings?
>> It supports the first approach only, in detail
>> - all warnings except a given subset
>> - you can add warnings, e.g. you might need -Wno-... for warnings that
>> are implicitly enabled. Especially with clang where '--help=warnings -Q'
>> isn't available. Here we use -Weverything and you have to add options to
>> silence some of the overly expressive warnings.
> OK, but a similar thing can be done for the opposite case (just with no
> -Weverything). So we could have two macros
>   gl_MANYWARN_GCC_ALL_EXCEPT([warnings to disable])

This is already there, you fill $WARN_CFLAGS with all C warn flags with
Now you can remove your unwanted warn flags via
  wget_WORD_REMOVE([WARN_CFLAGS], [$WARN_CFLAGS], [list of unwanted

>   gl_MANYWARN_GCC_ENABLE([warnings to enable])

see below...

>> It works only with gcc 4.3+.
> We can keep the existing, slower code around and use it for GCC versions
> < 4.2.
>>> Or also the case where you want only an explicitly specified set of
>>> warnings?
>> If you need that, why not just set CFLAGS ? Or maybe I don't understand
>> exactly...
> Because GCC freaks out when you pass it warning options that it does not
> understand. The whole point of this testing is to pass to GCC only those
> options that will not make it freak out.

I understand, but have a use case for this. It means I have to keep this
list up-to-date with each new compiler version (checking what is new and
if i want to add it to the list). That is maintenance burden I try to
avoid with my approach, were I automatically make use of new warning
flags. E.g. after the next 'apt upgrade' I might pull in gcc 9 and the
next build just might come up with new warnings...

Regards, Tim

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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