Re: Autoconf 2.52 is released

[Ralf Corsepius]

Paul Eggert wrote:
> 
> > Date: Wed, 25 Jul 2001 02:10:19 +0200
> > From: Ralf Corsepius <address@hidden>
> >
> > For me, it is subdir handling in autoconf-2.5x.
> 
> I don't use that, so I had no problem.  :-)
We have a large number of optional architecture-dependent
subdirectories and have been using AC_CONFIG_SUBDIRS($foo) to
control configuration of optional subdirectories.

Autoconf-2.5x requires the argument to AC_CONFIG_SUBDIRS not to
contain variables. This is hardly applicable in my case, as these
configure.ins try to provide an open framework which allows users to
add subdirectories. Consequently, we do not know these
subdirectories in advance and therefore can't hard-code them.

I am trying to work around this issue by implementing macros of my
own to avoid using autoconf's AC_CONFIG_SUBDIRS, but haven't got far
yet due to personal time-constraints.

> > A further problem is some of the new autoconf-features apparently
> > being immature and autoconf-2.5x (in most cases actually m4 or sh)
> > issuing cryptical error messages with encountering actual problems....
> > I also have seen autoconf-2.5x silently swallow autoconf-2.13
> > configure.ins without any complaint, while actually breaking them.
> 
> Have you sent in bug reports for these?
Not for all, but for some. The /lib/cpp issues, *_alias and
help-string problems are a subset of these.

However, from what I have seen, in most cases it's silently sharing
config.caches across subdirectories with autoconf-2.13 which
silently breaks if using autoconf-2.13 configure.ins with
autoconf-2.52. In many cases, such packages' configury claims to
continue being functional, while they actually get configured
differently in subdirectories than before (*_cv_* not found -> apply
default value instead of user-specified value).

Fortunately, m4-quoting issues in most cases cause autoconf, m4, sh
or other programs to choke, ie. these issues often are detected by
brute-force :)

Ralf