RE: Autoconf 2.52 is released

[Bernard Dautrevaux]

> -----Original Message-----
> From: Ralf Corsepius [mailto:address@hidden
> Sent: Thursday, July 26, 2001 1:28 PM
> To: Bernard Dautrevaux
> Cc: Paul Eggert; address@hidden; address@hidden
> Subject: Re: Autoconf 2.52 is released
> 
> 
> Bernard Dautrevaux wrote:
> > 
        <skipped>

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

I must agree here, but that's another problem. The original message was
talking about things that used to work and get broken by 2.52 :-)

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

I think you mean sth. in the line of

for file in */configure.in; do
 if test -r $file; then
  subdirs="$subdirs `dirname $file`"
 fi
done

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

Oh I see; you try to create a kind of automatically reconfigured top
configure script for not yet defined packages... Something that would be the
equivalent in autoconf of th ecygnus-configure, but with the added feature
that the configure script does NOT know what packages can be put below...

I think this would need quite a lot of new features in autoconf to be able
to work; first idea was that you then need a kind of dependency-definitions
(or generation...) between subpackages, if you don't want to put on package
builders a restriction like:

        "beware, subdirectories will be built in alphabetic order, so take
        this into account when naming dependant packages"

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

In fact I don't think such a macro could be implemented without getting deep
into autoconf's internals ;-|

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

I think I have done so (with some pre-2.52 CVS autoconf) and it worked, but
perhaps I do not take care of regenerating the auto-files. I don't NEED to
for lesstif, so I may have forgotten even if it's part of my standard build
procedures.

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