Re: Autoconf 2.52 is released

[Ralf Corsepius]

Bernard Dautrevaux wrote:
> 
> > -----Original Message-----
> > From: Ralf Corsepius [mailto:address@hidden
> > Sent: Wednesday, July 25, 2001 10:38 AM
> > To: Paul Eggert
> > Cc: address@hidden; address@hidden
> > Subject: Re: Autoconf 2.52 is released
> >
> >
> > 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 don't follow you here; currently (with 2.13) in such a case adding a
> subdirectory
> means adding in the base configure.in (or a file m4-sourced from it) an
> incantation like:
> 
>         subdirs="$subdirs my-new-subdir"
> 
> With autoconf-2.5x it should simply be replaced by
> 
>         AC_CONFIG_SUBDIRS(my-new-subdir)
> 
> and that should "Just Work"...
Exactly, and it does so perfectly in standard cases.

> Or is there something I don't see? 
May-be :)

Problems occur, if the subdir names change dynamical or if the names
of the subdirs are collected dynamical, ie. if the names of the
subdirs are not known in advance.

I am actually facing two different situations:

1) Evaluating and propagating target-subdirs, ie. to let building
take place into $target/subdir instead of subdir, with the sources
being in subdir.
[We use an automake based toplevel-configure.in to configure a
collection of packages and support 3-leaf Canadian Cross building,
using a configure.in having a functionality similar to the so-called
Cygnus toplevel configure.]

This has never worked with AC_CONFIG_SUBDIRS and never was supposed
to do, AFAIK. Here, autoconf actually lacks functionality, IHMO.

2) Allowing unknown config-subdirs below a configure script (This is
what I was referring to above).
Eg. given a situation similar to this:

configure.in
cpu1/configure.in
..
cpuN/configure.in

Until now, our autoconf-2.13 configure.in collected all subdirs from
directories below it and passed them as a shell variable to
AC_CONFIG_SUBDIRS, similar to what you described above:
for i in $files; do
 if test -d $file; then 
  subdirs="$subdirs $file"; 
 fi
done
AC_CONFIG_SUBDIRS($subdirs)

[$files is either derived from configuration options (eg. --target,
--host) or collected by shell-magic]

This allows users to drop-in a package cpuN+1 without us having to
know about it and without the user having to edit the configure.in.
AC_CONFIG_SUBDIRS new behavior prevents (more precisely, it
continues to work in most cases, but it complains about it) this.

> >
> > 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.
> 
> I don't think this is needed at all :-)
I don't think so (cf. above). 

> >
> > > > 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).
> 
> I never seen that, even when mixing 2.13 and 2.5x genetared configures, but
> I must confess that I'm using th econfig.cache only for what it's name said:
> a cache and not a way to pass defaults from one configure to another.
Try building an older version of lesstif with autoconf-2.52
generated auto*files and you will probably see.

Ralf