[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: incomplete warning message
From: |
Eric Blake |
Subject: |
Re: incomplete warning message |
Date: |
Mon, 20 Sep 2010 14:14:45 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100907 Fedora/3.1.3-1.fc13 Mnenhy/0.8.3 Thunderbird/3.1.3 |
On 08/30/2010 01:50 PM, Eric Blake wrote:
$ autoconf
configure.ac:63: warning: gl_LIBUNISTRING_LIBSOURCE was called before
gl_LIBUNISTRING
m4/libunistring-base.m4:21: gl_LIBUNISTRING_LIBSOURCE is expanded from...
m4/gnulib-comp.m4:148: gl_INIT is expanded from...
configure.ac:63: the top level
configure.ac:63: warning: gl_LIBUNISTRING_LIBHEADER was called before
gl_LIBUNISTRING
m4/libunistring-base.m4:53: gl_LIBUNISTRING_LIBHEADER is expanded from...
The last line looks like the stack trace would include at least one
more line.
But it ends abruptly.
I'm wondering if somehow the mere act of printing the backtrace is
deleting the stacktrace. I think this one should be easy enough to track
down before 2.68, so I'm reviving it on my list of hot TODO items this
week.
The backtrace produced by m4 is just fine. For proof, look at
autom4te.cache/traces.n (for the appropriate n). I think what is
happening is that autom4te is then passing these messages on through
perl, and perl is doing some sort of internal caching about whether a
particular warning line has already been printed, in which case it omits
the second printout. Since autom4te is handling each location line as a
separate warning, rather than passing the entire warning, location stack
and all, as a single entity, this means that all duplicated location
lines are getting squelched at the perl layer.
How to reproduce:
$ wget http://www.haible.de/bruno/gnu/autoconf-bug-20100531.tar.gz
$ tar xvfz autoconf-bug-20100531.tar.gz
$ cd autoconf-bug-20100531
$ autoconf
I saw it as well last week when cleaning up some gnulib
AC_COMPILE_IFELSE usage patterns.
This is the area of autom4te that is introducing the problem:
handle_traces ($req, "$tmp/warnings",
('_m4_warn' => "\$1::\$f:\$l::\$2::\$3$separator"));
# Swallow excessive newlines.
for (split (/\n*$separator\n*/o, contents ("$tmp/warnings")))
{
# The message looks like:
# | syntax::input.as:5::ouch
# | ::input.as:4: baz is expanded from...
# | input.as:2: bar is expanded from...
# | input.as:3: foo is expanded from...
# | input.as:5: the top level
my ($cat, $loc, $msg, $stacktrace) = split ('::', $_, 4);
msg $cat, $loc, "warning: $msg";
for (split /\n/, $stacktrace)
{
my ($loc, $trace) = split (': ', $_, 2);
msg $cat, $loc, $trace;
}
}
However, my perl is rather weak, so I'm not sure if I can quickly
correct it. Help would be appreciated.
Hmm, reading lib/Autom4te/Channels.pm is proving to be enlightening:
=item C<partial =E<gt> 0>
When set, indicates a partial message that should
be output along with the next message with C<partial> unset.
Several partial messages can be stacked this way.
Duplicate filtering will apply to the I<global> message resulting from
all I<partial> messages, using the options from the last (non-partial)
message. Linking associated messages is the main reason to use this
option.
For instance the following messages
msg 'channel', 'foo:2', 'redefinition of A ...';
msg 'channel', 'foo:1', '... A previously defined here';
msg 'channel', 'foo:3', 'redefinition of A ...';
msg 'channel', 'foo:1', '... A previously defined here';
will result in
foo:2: redefinition of A ...
foo:1: ... A previously defined here
foo:3: redefinition of A ...
where the duplicate "I<... A previously defined here>" has been
filtered out.
Linking these messages using C<partial> as follows will prevent the
fourth message to disappear.
msg 'channel', 'foo:2', 'redefinition of A ...', partial => 1;
msg 'channel', 'foo:1', '... A previously defined here';
msg 'channel', 'foo:3', 'redefinition of A ...', partial => 1;
msg 'channel', 'foo:1', '... A previously defined here';
Note that because the stack of C<partial> messages is printed with the
first non-C<partial> message, most options of C<partial> messages will
be ignored.
Maybe the solution is just to teach autom4te that warning outputs
consist of partial messages.
--
Eric Blake address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org
- Re: incomplete warning message,
Eric Blake <=