[Top][All Lists]

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

Re: [ANN] m4-1.4.17 released [stable]

From: David Bernier
Subject: Re: [ANN] m4-1.4.17 released [stable]
Date: Mon, 23 Sep 2013 13:03:25 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130917 Thunderbird/17.0.9

On 09/23/2013 11:30 AM, Eric Blake wrote:
> Hello Dago,
> On 09/23/2013 09:07 AM, Dagobert Michelsen wrote:
>> Hi Erik,
> It's Eric, but you're not the first to make that mistake :)
>>> I don't observe this behavior on my host (Sun Studio 12.3,
>>> Solaris 10 sparc).  I get the bad behavior only if I run
>>> 'configure' with the --enable-gcc-warnings option, and
>>> a simple workaround is to not use that option.
>> I didn't enable gcc-warnings, but as it turns out this flag is automatically
>> enabled when $srcdir/.git is present:
> Then as a workaround, use './configure --disable-gcc-warnings' until we
> fix the issue upstream.
>> However, when I browse git the automatic detection of .git is not in there:
>> http://git.savannah.gnu.org/gitweb/?p=m4.git;a=blob;f=configure.ac;h=2fe6d9e8189d4083b58ba10bfbbe558da15f393b;hb=c09a187c50f2f74e89d4d0991bdbd2c6846cc707
> You're browsing the wrong branch.  It IS present on branch-1.4, which is
> the source we used for cutting 1.4.17.
> http://git.savannah.gnu.org/gitweb/?p=m4.git;a=blob;f=configure.ac;h=2defd94f;hb=f58fbbd8
>> By coincidence we use git to apply patches in our build system
>> to upstream sources if necessary, so this is the thing that
>> confuses the build.
> Makes sense; it's hard to tell whether you are in a git repository for
> upstream development vs. a git repository that applies patches to a
> released tarball.  Maybe we can make the default be even smarter by
> recognizing a tarball-only file (ie. if .tarball-version exists, do NOT
> blindly enable gcc warnings) - but that will still only mask the problem
> of upstream gnulib's warning module getting the wrong answer for the Sun
> compiler.
>> When I disable using git in our buildsystem
>> the compilation works fine. I would prefer a system that enabled flags
>> explicitly and not by inspecting side effects but I can understand the
>> current behaviour.
> Yes, I'll patch m4 to use .tarball-version rather than just .git as the
> witness for whether a development build is being attempted; but there's
> still the matter of teaching gnulib's warning module how to recognize
> that '-fdiagnostics-show-option' and '-funit-at-a-time' are NOT valid
> warning flags for your compiler.  Does your compiler include any flag
> that forces the compiler to reject unknown warning parameters with
> non-zero exit status, instead of merely warning that they are being
> ignored until link phase?
> Paul, since you seem to have easy access to the same compiler, is this
> something where you can tackle the gnulib patch faster than I can?

I hope I will be forgiven for quoting everything.
Eric Blake wrote in part:
<< use './configure --disable-gcc-warnings' until <snip>  >>.

It seems that  GNU M4  is required before building GNU Autoconf,
and that Autoconf is used in creating "configure" shell scripts ...
Ref. to GNU Autoconf homepage:

Can Autoconf by given options? Or, what tells Autoconf how to write
a configure script, and where are the configure options set/defined?
In particular, the "--disable-gcc-warnings" option or flag?

Finally, what precedes in the Build Tool-chain "GNU M4"?


David Bernier

reply via email to

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