bug-autoconf
[Top][All Lists]
Advanced

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

Re: Weird error messages with duplicate AC_OUTPUT entries


From: Ralf Corsepius
Subject: Re: Weird error messages with duplicate AC_OUTPUT entries
Date: 10 Sep 2002 05:23:45 +0200

Am Mon, 2002-09-09 um 17.44 schrieb Akim Demaille:
> 
> | Hi,
> | When a configure.ac contains duplicate entries in its AC_OUTPUT,
> | running autoconf-2.53c generates bizarre error messages:
> | 
> | # cat configure.ac
> | AC_PREREQ(2.53c)
> | AC_INIT([hello],[0.0])
> | AC_CONFIG_SRCDIR([hello.c])
> | AM_INIT_AUTOMAKE([foreign])
> | AC_PROG_CC
> | AC_PROG_RANLIB
> | AC_CONFIG_FILES([Makefile Makefile])
> | AC_OUTPUT
> | 
> | # aclocal
> | # autoconf
> | configure.ac:7: error: `Makefile' is already registered with
> | AC_CONFIG_FILES.
> | /usr/src/packages/BUILD/autoconf-2.53c/lib/autoconf/status.m4:844:
> | AC_CONFIG_FILES is expanded from...
> | configure.ac:7: the top level
> | autom4te: /usr/bin/m4 failed with exit status: 1
> 
> Arg.  You are right, this is not very nice :(
Hmm, it actually is very confusing. 

I encountered this problem inside of the RTEMS source tree, where ~3-4
configure.ac of the ~150 configure.acs had contained duplicate files in
AC_OUTPUT - I had pretty unpleasant time to find out what goes wrong ;)

1. It wasn't easy to understand what actually went wrong:
(autoconf < 2.53 doesn't complain. For me, "Makefile is already
registered with AC_CONFIG_FILES" also was not self-explanatory when
seeing it for the first time. May-be "Duplicate entry Makefile in
AC_CONFIG_FILES" would have been)


2. It wasn't easy to find the files which caused the problem, because in
deep source trees with config-subdirs, the error message refers to the
"current configure.ac" autoconf/autom4te is working at, not to the
configure.ac inside of the config-subdirs.

3. If using autoreconf, the error message gets duplicated.


Example: 

Change the AC_CONFIG_FILES of sub/sub/configure.ac from my subtest demo
into AC_CONFIG_FILES([Makefile Makefile]) and run autoreconf from the
toplevel:

# autoreconf
autoreconf: `aclocal.m4' is unchanged
autoreconf: `aclocal.m4' is unchanged
autoreconf: `aclocal.m4' is unchanged
configure.ac:7: error: `Makefile' is already registered with
AC_CONFIG_FILES.
/usr/src/packages/BUILD/autoconf-2.53c/lib/autoconf/status.m4:844:
AC_CONFIG_FILES is expanded from...
configure.ac:7: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
configure.ac:7: error: `Makefile' is already registered with
AC_CONFIG_FILES.
/usr/src/packages/BUILD/autoconf-2.53c/lib/autoconf/status.m4:844:
AC_CONFIG_FILES is expanded from...
configure.ac:7: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
autoreconf: /opt/gnu/bin/autoconf failed with exit status: 1

Now try to answer: Which and how many files are broken?

Then imagine to have several dozen of config-subdirs in parallel to the
sub/sub directory ...


> | Also note: This also exposes a path from autoconf's the directory where
> | autoconf had been build. This directory is completely meaningless (and
> | not available) to users if using a installed copy of autoconf.
> 
> This is right too, but I see no means to solve this issue, unless when
> freezing, m4 decides to ``update'' the location of these files.
> That's an approximation, agreed, but one of the less false I can
> imagine :)
Well, of cause this is not a critical problem, but ..  we are talking
about production quality SW, designed to help users, here ;)

Ralf







reply via email to

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