bug-autoconf
[Top][All Lists]
Advanced

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

duplicate message are removed from autoreconf's verbose output


From: Alexandre Duret-Lutz
Subject: duplicate message are removed from autoreconf's verbose output
Date: Thu, 12 Jan 2012 17:36:17 +0100

The verbose output of autoreconf is very confusing for nested packages.

Consider this small example:

| % cat configure.ac
| AC_INIT([foo], [1.0])
| AC_CONFIG_SUBDIRS([bar])
| AC_OUTPUT
| % cat bar/configure.ac
| AC_INIT([bar], [1.0])
| AC_OUTPUT
| % autoreconf -vfi
| autoreconf: Entering directory `.'
| autoreconf: configure.ac: not using Gettext
| autoreconf: running: aclocal --force
| autoreconf: configure.ac: tracing
| autoreconf: configure.ac: adding subdirectory bar to autoreconf
| autoreconf: Entering directory `bar'
| autoreconf: configure.ac: not using Libtool
| autoreconf: running: /usr/bin/autoconf --force
| autoreconf: configure.ac: not using Autoheader
| autoreconf: configure.ac: not using Automake
| autoreconf: Leaving directory `bar'
| autoreconf: Leaving directory `.'


If you look at the output from autoreconf, it appears
that aclocal and autoconf have been run only once each:
- aclocal has been run for project foo, and
- autoconf has been run for project bar.


Of course aclocal and autoconf have been run on the two projects,
autoreconf is just hiding this information unintentionally.

If you look at the code for autoreconf, the intended output should be:

| % autoreconf -vfi
| autoreconf: Entering directory `.'
| autoreconf: configure.ac: not using Gettext
| autoreconf: running: aclocal --force
| autoreconf: configure.ac: tracing
| autoreconf: configure.ac: adding subdirectory bar to autoreconf
| autoreconf: Entering directory `bar'
| autoreconf: configure.ac: not using Gettext
| autoreconf: running: aclocal --force
| autoreconf: configure.ac: tracing
| autoreconf: configure.ac: not using Libtool
| autoreconf: running: /usr/bin/autoconf --force
| autoreconf: configure.ac: not using Autoheader
| autoreconf: configure.ac: not using Automake
| autoreconf: Leaving directory `bar'
| autoreconf: configure.ac: not using Gettext
| autoreconf: running: aclocal --force
| autoreconf: configure.ac: tracing
| autoreconf: configure.ac: not using Libtool
| autoreconf: running: /usr/bin/autoconf --force
| autoreconf: configure.ac: not using Autoheader
| autoreconf: configure.ac: not using Automake
| autoreconf: Leaving directory `.'

Unfortunately, all of these strings are printed via "verb()" which filters
out duplicate messages, hence the confusion.

Probably verb() could be taught not to filter messages.  (i.e., using

register_channel 'verb', type => 'debug', silent => 1, uniq_part => UP_NONE,
  ordered => 0

as in done automake).

Maybe these messages could be made directory dependent.  I think this
would be more helpful for debugging builds.  I'm thinking something
like this:

| % autoreconf -vfi
| autoreconf: Entering directory '.'
| autoreconf: ./configure.ac: not using Gettext
| autoreconf: running: 'aclocal --force' in '.'
| autoreconf: ./configure.ac: tracing
| autoreconf: ./configure.ac: adding subdirectory bar to autoreconf
| autoreconf: Entering directory 'bar'
| autoreconf: bar/configure.ac: not using Gettext
| autoreconf: running: 'aclocal --force' in 'bar'
| autoreconf: bar/configure.ac: tracing
| autoreconf: bar/configure.ac: not using Libtool
| autoreconf: running: '/usr/bin/autoconf --force' in 'bar'
| autoreconf: bar/configure.ac: not using Autoheader
| autoreconf: bar/configure.ac: not using Automake
| autoreconf: Leaving directory 'bar'
| autoreconf: ./configure.ac: not using Gettext
| autoreconf: running: 'aclocal --force' in '.'
| autoreconf: ./configure.ac: tracing
| autoreconf: ./configure.ac: not using Libtool
| autoreconf: running: '/usr/bin/autoconf --force' in '.'
| autoreconf: ./configure.ac: not using Autoheader
| autoreconf: ./configure.ac: not using Automake
| autoreconf: Leaving directory '.'


--
Alexandre Duret-Lutz



reply via email to

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