RE: Autoconf 2.52 is released

[Bernard Dautrevaux]

> -----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"... Or is there something I don't see?

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

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

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

Unfortunately, this is not always the case; I've seen cases where the
configure script just fails (in some cases with the dreaded "Unexpected end
of file at configure:6543") or where it seems to complete correctly but does
not configure the package correctly... However I must confess that I have
these problems mainly with pre-2.50-released CVS autoconfs ;-(

Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:    +33 (0) 1 47 68 80 80
Fax:    +33 (0) 1 47 88 97 85
e-mail: address@hidden
                address@hidden
--------------------------------------------