Re: configure and -Werror=unused-variable do not mix well.

[ISHIKAWA,chiaki]

Dear Eric,

Thank you for your quick response.

On 2017/01/28 0:00, Eric Blake wrote:
> On 01/27/2017 05:31 AM, address@hidden wrote:
> > In configure script generated by autoconf 2.13 for mozilla software
> >
> > # Generated automatically using autoconf version 2.13
> > # Copyright (C) 1992, 93, 94, 95, 96 Free Software Foundation, Inc.
>
> Wow that's old. Can you convince the project to upgrade their
> configure.in file to use autoconf 2.69 instead?

I realize that I do have both autconf213 and autoconf (2.69) on MY linux 
PC (Debian GNU/Linux).

Not sure, though. how the Mozilla developers would update the manner to 
create configure from configure.in.
It seems that they have abandoned the route and try moving into their 
own configuration tool written in python.
In the meantime, the old configure is left as old-configure and is 
executed and old-configure.in has, near the beginning, the following lines:
dnl Process this file with autoconf to produce a configure script.
dnl ========================================================
AC_PREREQ(2.13)  <==== !?
AC_INIT(config/config.mk)
AC_CONFIG_AUX_DIR(${srcdir}/build/autoconf)
AC_CANONICAL_SYSTEM

Does AC_PRERQ(2.13) require the use of autoconf213?
Or can we use autoconf (2.69) safely? If we can use later versions 
safely, I would certainly suggest upgrading to mozilla's mailing list.

> > I found a few tests that failed if -Werror=unsed-variable is defined for
> > CFLAGS (an environment variable).

After sending out my report, I thought about it and I agree that 
-Werror=...  would be nightmarish to deal with as you mention near the 
beginning of next paragraph:

> Generally, ANY use of -Werror during configure is going to cause
> problems. Our general advice is "don't do that".  If you want to test if
> a particular warning flag is supported, do so (and in fact, there's
> patches posted that I still want to incorporate into autoconf 2.70 that
> make warning flag probing easier) - but only for the duration of that
> test.  Don't actually change CFLAGS for the rest of the configure suite.
>  GNU Coreutils is a good example of how to probe for -Werror and even
> use it via a separate Makefile.am variable, without having it on to mess
> with the rest of the configure probes.

What is puzzling me right now is that
I have two Debian GNU/Linux with very similar configuration and
on one machine I get the problem which I reported, but
on the other machine somehow I do NOT get the problem.
Very confusing...
(Not only that on the other machine, as of today, I noticed a GCC 6 
crash (dreaded internal compiler error), but not on this machine where I 
am writing  this e-mail.
I am driven nuts...

There may be a subtle configuration difference somewhere [this machine I 
use fetches more ambitious testing packages while the other PC is in an 
office setting and use more stable package repository], but
this kind of subtle issue may be exactly why we should avoid
using -Werror during configure.

If I have time I would love to check how GNU Coreutils handles this issue.

The reason I had to add "-Werror=unused-variable" to my CFLAGS 
environment variable is that Mozilla's compilation farm available to 
developers seems to apply this -Werror setting per directory basis, and 
in order to detect such warning-turned-into-error locally on my 
home/office PC [I found a few compilation errors ONLY AFTER I submit my 
source patches to mozilla's compilation farm. The source compiled fine 
on my PCs.], I had to add this -Werror, but I was not sure how to apply 
the option per directory-basis in the framework mozilla uses to build 
firefox browser and thunderbird mail client.
Right now, I apply the CFLAGS setting for the whole source tree.

Their command to build is very complex and handles the configure and 
build in one command and it is not easy to separate the two.

Thank you again for your feedback.

Best Regards,
Chiaki Ishikawa