Testing for unknown flags in different compilers

[Dale Visser]

I have been working on a changes whereby an autoconf user can invoke a macro like

AC_WARN_ADD([-Wextra])

to add user-specified flags to the compiler/linker invocations. Ideally we would like

AC_WARN_ADD([-Wunknown-warning-flag])

to not add the offending unknown flag. My initial implementation couldn't detect and suppress unknown flags in the LLVM clang/clang++ compiler. Eric Blake pointed me to the gnulib warnings module which has a clever way utilizing "-Wunknown-warning-option -Werror" to handle this: http://lists.gnu.org/archive/html/autoconf-patches/2014-02/msg00006.html

Wanting to be thorough, I checked whether unknown flags would also get suppressed by the Intel C++ compiler. It turns out that AFAICT the Intel compiler never exits with a non-zero status for unknown flags, eliminating the usual way of testing in autoconf. (See also https://stackoverflow.com/questions/14820890/intel-compilers-silence-commandline-warnings)

I would like to take the following approach, and want to see if the community has any helpful advice on whether this is advisable or ways to improve on it:

IF perform test compile with given flag (e.g., -Wunknown-warning-flag) (using above-mentioned strategy so LLVM will detect, too) is successful(true) THEN
Perform test compile with unknown flag, redirecting stdout and stderr to fileA
Perform test compile without unknown flag, redirecting stdout and stderr to fileB
IF "diff fileA fileB | grep --quiet -- -Wunknown-warning-flag" is successful (true) THEN
Flag is unknown. Do not add to flags.
ELSE
Success. Add to flags. It was not explicitly mentioned in output, so must be known.
FI
ELSE
Flag is unknown. Do not add to flags.
FI

Please let me know if you see any problems or pitfalls with this approach.

Best regards,
Dale Visser

[David A. Wheeler]

> I have been working on a changes whereby an autoconf user can invoke a macro like

AC_WARN_ADD([-Wextra])

> to add user-specified flags to the compiler/linker invocations.
> Ideally we would like

AC_WARN_ADD([-Wunknown-warning-flag])

> to not add the offending unknown flag.

I like the goal. I wonder if "AC_WARN_ADD" is the right macro name.
After all, this could add any flag or flag sequence, as long as the compiler accepts it.

Perhaps another name like "AC_ADD_FLAG_IFVALID" or whatever
would be a better name. I don't care exactly what the *name* is, as long as it's clear.

--- David A. Wheeler

[Thomas Jahns]

Hello all,

On 02/19/14 22:05, Dale Visser wrote:
> I have been working on a changes whereby an autoconf user can invoke a macro like
>
> AC_WARN_ADD([-Wextra])
>
> to add user-specified flags to the compiler/linker invocations. Ideally we would like

I'm unclear what tool(s) you want to affect (is the flag going to be added to
CFLAGS, CXXFLAGS, FCFLAGS? depending on language mode or CFLAGS only? if the
latter shouldn't the name have something like CC in it).

Also this is going to cause all sorts problems for compilers that use -W for
something else entirely, for example on PowerPC xlc has

-W<program>,<options_list>

so simply adding some arbitrary -Wsomecharactersequence might easily cause
catastrophic results later on. I suggest your macro at least try to make sure
your compiler is GNU CC before modifying CFLAGS in any way.

Also users should have an option to deselect this because software tends to get
distributed to systems where system headers cause one warning or another.

In my opinion you are trying to solve a development issue with a tool that has
the explicit purpose of being useful for non-developers.

Regards, Thomas
--
Thomas Jahns
DKRZ GmbH, Department: Application software

Deutsches Klimarechenzentrum
Bundesstraße 45a
D-20146 Hamburg

Phone: [phone]
Fax: [phone]
Email: Thomas Jahns <***@dkrz.de>

[Dale Visser]

Thomas:

Your concerns make sense. I was deliberately vague about the context and purpose of the macro, since I wanted the list community to focus on whether the algorithm I was proposing is the best way of accomplishing the stated goal of adding a compiler/linker flag *only* if it is known to the compiler.

If you follow the link to the autoconf-patches discussion I provided earlier, it gives the context, which I'll describe here. I am attempting to modify and port macros from autoconf-archive and gnulib-warnings to modify the default behavior of AC_PROG_CC, AC_PROG_CXX and AC_PROG_FC to add option flags to turn on compiler warnings. E.g., in gcc and clang, -Wall would be added.

Since not all developers would be happy with this new default, a way is provided to restore the previous behavior (not adding the warning options). *In addition*, a new macro will be provided to make it easy for configure.ac authors to add flags to the CXXFLAGS, CFLAGS, or FCFLAGS as appropriate by context. For example, a team may be happy with -Wall except for the fact that it includes warnings about the contents of comments, and so could invoke AC_ADD_CXXFLAG_IFVALID([-Wno-comment]) in order to turn that warning off. (A better name than AC_WARN_ADD, as David Wheeler pointed out.)

Your point about clx makes sense. I was not aware of its different usage of -W (documented at http://pic.dhe.ibm.com/infocenter/comphelp/v121v141/index.jsp?topic=%2Fcom.ibm.xlcpp121.aix.doc%2Fcompiler_ref%2Fopt_w_upper.html). My goal is to make the AC_PROG_* changes as cross-compiler as possible. There is probably always going to be some compiler which does its various command-line options different than the others. The AC_ADD_*FLAG_IFVALID macro would be very much a "buyer beware" macro, and almost by definition, people are going to placing flags there that will be specific to a given compiler, hence the desire to detect ones unknown to the current compiler and reject them.

Best regards,
Dale Visser

Date: Thu, 20 Feb 2014 11:26:35 +0100
From: ***@dkrz.de
To: ***@gnu.org
Subject: Re: Testing for unknown flags in different compilers

Hello all,

On 02/19/14 22:05, Dale Visser wrote:
> I have been working on a changes whereby an autoconf user can invoke a macro like
>
> AC_WARN_ADD([-Wextra])
>
> to add user-specified flags to the compiler/linker invocations. Ideally we would like

I'm unclear what tool(s) you want to affect (is the flag going to be added to
CFLAGS, CXXFLAGS, FCFLAGS? depending on language mode or CFLAGS only? if the
latter shouldn't the name have something like CC in it).

Also this is going to cause all sorts problems for compilers that use -W for
something else entirely, for example on PowerPC xlc has

-W<program>,<options_list>

so simply adding some arbitrary -Wsomecharactersequence might easily cause
catastrophic results later on. I suggest your macro at least try to make sure
your compiler is GNU CC before modifying CFLAGS in any way.

Also users should have an option to deselect this because software tends to get
distributed to systems where system headers cause one warning or another.

In my opinion you are trying to solve a development issue with a tool that has
the explicit purpose of being useful for non-developers.

Regards, Thomas
--
Thomas Jahns
DKRZ GmbH, Department: Application software

Deutsches Klimarechenzentrum
Bundesstraße 45a
D-20146 Hamburg

Phone: [phone]
Fax: [phone]
Email: Thomas Jahns <***@dkrz.de>

[David A. Wheeler]

Thomas Jahns:
> Also this is going to cause all sorts problems for compilers that use -W for
> something else entirely, for example on PowerPC xlc has
> -W<program>,<options_list>
> so simply adding some arbitrary -Wsomecharactersequence might easily cause
> catastrophic results later on.

I think that's the whole point of the macro; instead of just adding arbitrary flags,
it tests to make sure there are *not* catastrophic effects, but instead, that
the flag is recognized.

> I suggest your macro at least try to make sure
> your compiler is GNU CC before modifying CFLAGS in any way.

I like GNU CC, but I think that would be a mistake.
There are other compilers out there!!

Autoconf should make it easy to automatically work with the
varying compilers (including automatically enabling whatever warning
flags they support, and allowing developers to control them more finely
for their particular project in a relatively compiler-agnostic way).

--- David A. Wheeler

[Eric Blake]

On 02/20/2014 08:12 AM, David A. Wheeler wrote:
> Thomas Jahns:
>> Also this is going to cause all sorts problems for compilers that use -W for
>> something else entirely, for example on PowerPC xlc has
>> -W<program>,<options_list>
>> so simply adding some arbitrary -Wsomecharactersequence might easily cause
>> catastrophic results later on.
>
> I think that's the whole point of the macro; instead of just adding arbitrary flags,
> it tests to make sure there are *not* catastrophic effects, but instead, that
> the flag is recognized.

Or at least has no observable negative effects even if it is a no-op to
a particular compiler by including the flag.

--
Eric Blake eblake redhat com [phone]
Libvirt virtualization library http://libvirt.org

[Bob Friesenhahn]

On Wed, 19 Feb 2014, Dale Visser wrote:

> I have been working on a changes whereby an autoconf user can invoke a macro like
>
> AC_WARN_ADD([-Wextra])
>
> to add user-specified flags to the compiler/linker invocations. Ideally we would like

I don't think that it is a particularly good idea to enable any
warning options by default in a package unless the warnings are likely
to indicate that the code the developer should have already perfected
is somehow faulty (e.g. unexpected interface definition or missing
prototype) on the system it is being built on.

Usually only the developers of a package are interested in seeing and
fixing warnings. Warnings are only a cause for concern (usually undue
concern) for others.

There are many people who build packages from source code besides the
package developers.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

[Julien ÉLIE]

Hi Bob,

>> I have been working on a changes whereby an autoconf user can invoke a
>> macro like
>>
>> AC_WARN_ADD([-Wextra])
>>
>> to add user-specified flags to the compiler/linker invocations.
>
> I don't think that it is a particularly good idea to enable any warning
> options by default in a package unless the warnings are likely to
> indicate that the code the developer should have already perfected is
> somehow faulty (e.g. unexpected interface definition or missing
> prototype) on the system it is being built on.
>
> Usually only the developers of a package are interested in seeing and
> fixing warnings. Warnings are only a cause for concern (usually undue
> concern) for others.

I believe the suggested macro could be worthwhile (from the standpoint
of a developer) in the case of building a software on various OSes on
different platforms (for instance the GCC C Farm servers).
One could then have a WARNINGS variable in his Makefile with the
recognized flags on the platform (thanks to checks done by several calls
to the suggested AC_WARN_ADD macro, that incidentally should have a
second variable to tell which variable to populate -- for instance here,
the WARNINGS variable).

Then, for automatic builds on several OSes, I would only have to run
"make warnings" that I would have told to run the compiler with
$WARNINGS appended.
This way, no need to worry about the set of flags available on the
platform. It would be found out automatically.
Of course, apart from automatic builds, it could be useful for manual
builds (by developers running "make warnings").


Though I agree that it is not a good idea to add these flags by default
to the end user, the feature could be useful for other people.

--
Julien ÉLIE

« Tous les champignons sont comestibles. Certains, une fois
seulement. »

[Carsten Heinrici]

Hi Julie



>>> I have been working on a changes whereby an autoconf
>>> user can invoke a macro like
>>>
>>> AC_WARN_ADD([-Wextra])

The point is the portability. Your flags (-Wextra) depend on the actual compiler. This js against the philosophy behind autoconf, which tries to abstract from it.

If wanted, a developper always can add additional specific compiler flags during runtime by specifying them via CFLAGS on command line.

What would be required is a general macro AC_EXTRA_WARNINGS without arguments which could resolve to the actually current arguments of the tool.

Carsten

[Eric Blake]

On 02/21/2014 03:01 PM, Carsten Heinrici wrote:
> Hi Julie
>
>
>
>>>> I have been working on a changes whereby an autoconf
>>>> user can invoke a macro like
>>>>
>>>> AC_WARN_ADD([-Wextra])
>
> The point is the portability. Your flags (-Wextra) depend on the actual compiler. This js against the philosophy behind autoconf, which tries to abstract from it.

No, this is totally in line with autoconf philosophy - the point is to
call AC_WARN_ADD for a large set of flags that have been shown to work
in at least one compiler, and then for each flag in that set, only
enable the flags that the current compiler actually honors (or at least
silently ignores). The proposal is not to blindly add the gcc-specific
-Wextra flag to all $CC runs, but rather to test if $CC supports
-Wextra, and if so, THEN add -Wextra to a variable (we probably also
want the user to be able to control whether it is added directly to
CFLAGS or to some other variable, the way the gnulib module
'manywarnings' already does).

>
> If wanted, a developper always can add additional specific compiler flags during runtime by specifying them via CFLAGS on command line.

This will still remain true. And the developer's choice of CFLAGS
should always take precedence over any default flags that autoconf
probes for in the absence of a developer preference.

>
> What would be required is a general macro AC_EXTRA_WARNINGS without arguments which could resolve to the actually current arguments of the tool.

Yes, AC_EXTRA_WARNINGS (or whatever spelling gets agreed on) would be
the wrapper that has a huge list of known warning flags that various
compilers honor, and calls AC_WARN_ADD on each of them, so that for your
given $CC, you have then set a variable with the subset of warning flags
that made sense for your compiler.

--
Eric Blake eblake redhat com [phone]
Libvirt virtualization library http://libvirt.org

[Bob Friesenhahn]

On Fri, 21 Feb 2014, Eric Blake wrote:

> This will still remain true. And the developer's choice of CFLAGS
> should always take precedence over any default flags that autoconf
> probes for in the absence of a developer preference.

This statement is one that I definitely believe in but it makes the
grave assumption that it is possible to undo/override options
specified in left to right order. This works for GCC but definitely
not compilers at large. How would compilers be supported which do not
provide the ability to remove an already supplied option?

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

[Eric Blake]

On 03/07/2014 02:07 PM, Bob Friesenhahn wrote:
> On Fri, 21 Feb 2014, Eric Blake wrote:
>
>> This will still remain true. And the developer's choice of CFLAGS
>> should always take precedence over any default flags that autoconf
>> probes for in the absence of a developer preference.
>
> This statement is one that I definitely believe in but it makes the
> grave assumption that it is possible to undo/override options specified
> in left to right order. This works for GCC but definitely not compilers
> at large. How would compilers be supported which do not provide the
> ability to remove an already supplied option?

Probably how we already handle non-default CFLAGS:

If CFLAGS is unspecified, we choose defaults for you (currently '-g -O2'
for gcc and '-g' for other compilers - this proposal adds several
'-W...' for gcc and various other tested-to-work options for other
compilers). But if you specify CFLAGS we honor your choice completely
(and don't try to inject our defaults)

Maybe there's some fine-tuning involved - we compute the default
warnings, and stick it on the left of CFLAGS even if you explicitly
override CFLAGS, but provide yet another envvar or command line option
to disable all warnings probes; although for warnings to work by default
this secondary variable has to eventually feed CFLAGS (because any other
solution would require using a new variable in makefiles, which means
its no longer a default-on improvement to the toolchain).

There's also two levels of defaults - one is whether configure files
should start probing for warnings by default (configure.ac authors
should have final say on probing for additional warnings or bypassing
the warning probes altogether, in the case where they don't like
autoconf defaults), another at the end user level (configure users
should have final say on whether to trust the configure.ac choice of
CFLAGS, or to provide their own).

--
Eric Blake eblake redhat com [phone]
Libvirt virtualization library http://libvirt.org

[David A. Wheeler]

Bob Friesenhahn <***@simple.dallas.tx.us> stated:
> I don't think that it is a particularly good idea to enable any
> warning options by default in a package unless the warnings are likely
> to indicate that the code the developer should have already perfected
> is somehow faulty (e.g. unexpected interface definition or missing
> prototype) on the system it is being built on.
>
> Usually only the developers of a package are interested in seeing and
> fixing warnings. Warnings are only a cause for concern (usually undue
> concern) for others.

I strongly disagree.

I think many *end-users* want to know about warnings too. By end-users, I mean people who are NOT developers but are compiling the code, including distro packagers. If I compile software and I can see that it triggers LOTS of compile-time warnings, that’s a big hint on how much care the developers are taking in the quality of their software. It’s not a perfect correlation; good software can sometimes trigger many errors, and bad software can be warning-free. Still, when you’re looking at new-to-you software, these warnings are a data point worth knowing.

This isn't just speculation. I just recently downloaded a new-to-me program (in this case, Metamath), and to roughly measure its quality, I simply turned on gcc warning flags (in my case "-Wall -Wextra") to see how clean it was when I compiled it. It turned out there were *NO* warnings. Sure, that doesn’t mean the software is perfect, but that *did* suggest to me a quality of care.

I think *many* people agree that warnings can be useful. E.G., Keith Packard recently worked to eliminate the warnings from X windows (http://keithp.com/blogs/xserver-warnings/). He said, “One of the developers was looking over my shoulder while the X server was building and casually commented on the number of warnings generated by the compiler…. I felt like I had invited someone into my house without cleaning for months — embarrassed and ashamed that we’d let the code devolve into this state.”

But how can we make sure that developers are more likely to see or heed these warnings? Well, if they're on by default, developers are more likely to see them of course. But it's important that *users* also see them, if for no other reason than that developers will know that *users* who compile the program will see the same errors (and thus have an incentive to fix them). And Dale Visser is also working on a way to portably *control* these flags for cases where a particular flag isn't appropriate (or should be added), so there's no problem if the default is not so great for your specific program.

I think it is NOT a good idea for a developer to see warning messages in his builds, but then suppress them for end-user builds. Better to suppress them with good reason for all builds, if they are not relevant! Or if not, at least document why certain warnings are not being "fixed"... and they're way more likely to be fixed or documented if the users can easily see them.

--- David A. Wheeler

[Bob Friesenhahn]

On Fri, 21 Feb 2014, David A. Wheeler wrote:
>

> I think it is NOT a good idea for a developer to see warning
> messages in his builds, but then suppress them for end-user builds.
> Better to suppress them with good reason for all builds, if they are
> not relevant! Or if not, at least document why certain warnings are
> not being "fixed"... and they're way more likely to be fixed or
> documented if the users can easily see them.

Sorry for being so late to return to this discussion thread ...

To be sure, I am a firm believer in warnings. Unfortunately, warnings
are very much compiler and compiler version dependent. Some compilers
produce many spurious warnings when set to a high warnings level.

If Autoconf (or packages using it) engages a high warning level by
default then GCC and other compilers will be less likely to include
useful warnings in options like -W -Wextra because they will cause
embarrasing build noise in most software. This is also
counter-productive to the cause.

Warnings should be seen by people who have an interest in and ability
to fix them.

There are other sorts of warnings (often more serious) which are being
soundly ignored by developers and users and continue unabated for
years. Take a look at .xsession-errors (or equivalent) on any desktop
oriented system for an example of this.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

[Paul Eggert]

Bob Friesenhahn wrote:
>
> If Autoconf (or packages using it) engages a high warning level by default

I don't think anybody's advocating that. It'd be an option. The
typical practice is for packages to have a build-time option like
'./configure --enable-gcc-warnings' which some developers use but most
builders do not.

[Bob Friesenhahn]

On Thu, 6 Mar 2014, Paul Eggert wrote:

> Bob Friesenhahn wrote:
>>
>> If Autoconf (or packages using it) engages a high warning level by default
>
> I don't think anybody's advocating that. It'd be an option. The typical
> practice is for packages to have a build-time option like './configure
> --enable-gcc-warnings' which some developers use but most builders do not.

I am definitely supportive of that sort of approach. If it is
implemented, then it should be in a consistent way.

Many free software developers are now using compilers other than GCC
on a daily basis (e.g clang) so it would be good if the approach is
not entirely GCC specific.

Bob
--
Bob Friesenhahn
***@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/

[David A. Wheeler]

Thomas Jahns said:
> >> Also this is going to cause all sorts problems for compilers that use -W for
> >> something else entirely, for example on PowerPC xlc has
> >> -W<program>,<options_list>
> >> so simply adding some arbitrary -Wsomecharactersequence might easily cause
> >> catastrophic results later on.

I said:
> > I think that's the whole point of the macro; instead of just adding arbitrary flags,
> > it tests to make sure there are *not* catastrophic effects, but instead, that
> > the flag is recognized.

Eric Blake added:
> Or at least has no observable negative effects even if it is a no-op to
> a particular compiler by including the flag.

Yes, that's fair point.

It appears to me that the code to work out the *default* warning flags goes further and intentionally checks for flag sets known to work (or not work) for a larger set of specific compilers, so that shouldn't be a problem for the default case anyway.

But as for Dale Visser's macro to check if a possible additional compiler flag is "okay", I looked at the listed HTML page for the IBM compiler mentioned earlier: http://pic.dhe.ibm.com/infocenter/comphelp/v121v141/index.jsp?topic=%2Fcom.ibm.xlcpp121.aix.doc%2Fcompiler_ref%2Fopt_w_upper.html
where it shows "-W..." doing all sorts of things, using examples such as "-Wl,-berok". That's an unfortunate overload of "-W...".

I think that problem can be addressed in many cases by forcing the macro to test for a successful *compile* and *link*, instead of just *compile*. That way, the linker will have a chance to complain, which the macro can then detect. Then the flag will only be added if it causes no observable negative effects in compiler or link... which seems like an improvement.

Also, if Dale Visser adds a macro that just *detects*, but doesn't necessarily *add*, then people can easily implement sequences like, "if '-pedantic -Wall' works, then try to add flag '-Wall'". That should make it much easier to portably add option flags when a particular flag sequence has different meanings between compilers. That's what the code for computing the default warning flags does anyway; this change would make that functionality easily accessible to users.


--- David A. Wheeler

[David A. Wheeler]

Dale Visser:
>>> I have been working on a changes whereby an autoconf
>>> user can invoke a macro like
>>> AC_WARN_ADD([-Wextra])

Carsten Heinrici:
> The point is the portability. Your flags (-Wextra) depend on the actual
> compiler. This js against the philosophy behind autoconf, which tries to
> abstract from it.

I disagree, I think this is EXACTLY in the spirit of autoconf.
AC_WARN_ADD is a probe, just like many other autoconf macros.
In this case, this probe determines if "-Wextra" would be okay to add to
the (current) compiler flag, and adds it ONLY if it's okay to add to add it.

I think the macro needs a better name, e.g., "AC_ADD_FLAG_IFVALID" or something.
As far as I can tell this flag-probing macro isn't limited to warnings at all,
so its name may as well reflect that. That said, enabling or disabling
warnings is what *I* would use this macro for.

> What would be required is a general macro AC_EXTRA_WARNINGS without arguments
> which could resolve to the actually current arguments of the tool.

Dale Visser is also proposing something like this, though by default.
I think it is *vitally* important that warning flags be on by *default*,
as I've posted earlier. If it's only an option, then in many cases developers and users
will fail to see the warnings that often hint at serious problems
(as sadly happens now).

--- David A. Wheeler

[David A. Wheeler]

David A. Wheeler wrote:
> > I*AM* advocating a*basic* warning level by default.
> > I interpret that on gcc to be "-Wall" or some variant.

Paul Eggert:
> -Wall generates too many false positives in practice. Perhaps some
> variant would be better, but we'd have to see the details.

I get the impression that even if "-Wall" has too many false positives,
there are one or two options that can be added to address that
when using gcc (per previous discussion on autoconf mailing lists).
So the default for gcc could be dialed to "-Wall -_whatever_".

> I doubt whether all developers will agree about this, so it'll be useful
> to have an option that can be set in configure.ac. Packages whose
> developers like the commonly-used './configure --enable-gcc-warnings'
> approach could specify in configure.ac that warnings are off by
> default. Packages whose developers like basic warnings (whatever they
> are) enabled by default could do that too.

I agree. I think it's *important* that warnings should be enabled by default,
as I noted earlier, but also I agree that making warnings the default
will *only* be acceptable if developers can easily disable or tweak
the warning flags for their specific project.

Adding mechanisms to do this, regardless of the compiler in use, would
be a big step forward.

--- David A. Wheeler

[Dale Visser]

> From: ***@dwheeler.com
> To: ***@gnu.org
> Subject: Re: Testing for unknown flags in different compilers
> Date: Fri, 7 Mar 2014 12:26:45 -0500
> ...
> I agree. I think it's *important* that warnings should be enabled by default,
> as I noted earlier, but also I agree that making warnings the default
> will *only* be acceptable if developers can easily disable or tweak
> the warning flags for their specific project.
>
> Adding mechanisms to do this, regardless of the compiler in use, would
> be a big step forward.

My work on this has been on hold for the last week, but I am planning to augment the current mechanism for tweaking the flags with a command-line option that will be usable to quickly disable the feature without having to edit configure.ac. E.g.:

> autoreconf -f -i
> ./configure --no-default-warnings

I'm still not sure on the exact naming of the option.

Best regards,
Dale Visser

[David A. Wheeler]

On Fri, 7 Mar 2014 15:51:49 -0500, Dale Visser <***@live.com> wrote:
> My work on this has been on hold for the last week, but I am planning to augment the current mechanism for tweaking the flags with a command-line option that will be usable to quickly disable the feature without having to edit configure.ac. E.g.:
>
> > autoreconf -f -i
> > ./configure --no-default-warnings
>
> I'm still not sure on the exact naming of the option.

Great, I'm looking forward to it.

I think "--no-default-warnings" (and presumably "--default-warnings") is clear enough.
Since they are *not* gcc-specific, the name "gcc" should not be in the name of the configure flag.

--- David A. Wheeler