bug-autoconf
[Top][All Lists]
Advanced

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

CVS version autoreconf fails w/ aclocal 1.8.3 in subdirs if _AC_ pattern


From: ezra peisach
Subject: CVS version autoreconf fails w/ aclocal 1.8.3 in subdirs if _AC_ pattern in configure.in
Date: Tue, 13 Apr 2004 14:16:57 -0400 (EDT)


Short synopsis...

Have been using autoconf for years... Setup is been to have a
top level aclocal.m4 file, but multiple configure.in files in subdirs
as referenced by AC_CONFIG_SUBDIRS invocations.

If the subdir configure.in has a pattern that looks like one recognized by 
autoconf, i.e. KRB5_AC_OUTPUT, autoreconf will fail in the aclocal invocation.

Testing out the cvs version of autoconf w/ automake 1.8.3 installed,
autoreconf will descend into the subdir and invoke 

"aclocal --force"

which invokes 

autom4te --language Autoconf-without-aclocal-m4   configure.in

The right thing happens if the subdir configure.in is complete and
does not require anything from the top level aclocal.m4... I.e. one
could defined the KRB5_AC_OUTPUT in here - and all is happy, but if
one needs the top level aclocal.m4:

configure.in:21: error: possibly undefined macro: KRB5_AC_OUTPUT
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

and the reconfiguration fails.  Given that I do not need an aclocal.m4
file generated, things should continue... autoconf being run on this
directory will be fine, because the definition for KRB5_AC_OUTPUT exists

Now - in autoreconf, with say aclocal version 1.6 in the path, autoreconf
will do the aclocal --output=aclocal.m4t

which does not create the appropriate aclocal.m4 - as is expected...


So - the problem is sort of complicated:

a) I don't need an aclocal.m4 in the subdir

b) aclocal --force should not be so smart fail on macros that may not
be defined that match a pattern such as _AC_.

c) autoconf -I../.. still works... The ../../aclocal.m4 defined
KRB5_AC_OUTPUT.  If it failed to do so, the pattern _AC_ will be picked up by 
autoconf and a failure will occur.

d) One should not be prohibited from using _AC_ in a macro name... It
is useful to detect errors.

>From the documentation (autoconf.texi):

"To ensure that your macros don't conflict with present or future
Autoconf macros, you should prefix your own macro names and any shell
variables they use with some other sequence."

No where does it indicate that _AC_ should not be used. 

My solution: I do not have one at this time....

Ezra




reply via email to

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