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: Akim Demaille
Subject: Re: Weird error messages with duplicate AC_OUTPUT entries
Date: 10 Sep 2002 15:24:56 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Honest Recruiter)

| > | # 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. 

My problem is that it does happen that some error due to some user
input, reveal themselves in a deep internal call.  And the whole back
trace is very useful when trying to understand the real problem.

Nevertheless, you are right, maybe we should scan all the m4_fatal and
isolate those that are not subject to this problem.  Such this one.



| 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)

Please, do not hesitate sending suggestions in a patch format :)
Note that the later message is *less* specific than the first:

/tmp % cat configure.ac                                          nostromo 13:02
AC_INIT
AC_CONFIG_FILES(Makefile.h)
AC_CONFIG_HEADERS(Makefile.h)
AC_OUTPUT
/tmp % autoconf                                                  nostromo 13:02
configure.ac:3: error: `Makefile.h' is already registered with AC_CONFIG_FILES.
/home/lrde/prof/akim/src/ace/lib/autoconf/status.m4:421: AC_CONFIG_HEADERS is 
expanded from...
configure.ac:3: the top level
autom4te: /usr/local/bin/m4 failed with exit status: 1



| 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.

Arg...  You are right...  This is to be solved.  I don't think
autoconf and others should be verbose, do you?  I mean, I have never
really understand why autoheader is verbose, but autoconf etc. are
not.  I tend to think it is autoheader which is wrong and should be
silent.  But if other people claim the opposite, I'm OK with adding
more `foo is updated/created/not changed' messages.

Still, autoreconf'ing deep tree is yet another problem, which I don't
feel compelled to fix in 2.54.  Do you consider this a major problem?



| 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

Arg.  By default, `chdir' should be announced, you are right.  Or, and
that would be better for `M-x compilation' runs, the messages should
include the path.

But again, that's too late for 2.54.


| 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
0.| 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?

Arg :)  Try `-v'.


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

Yes, this is really bad, sorry :(




reply via email to

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