> -----Original Message-----
> From: Ralf Corsepius [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, July 26, 2001 1:28 PM
> To: Bernard Dautrevaux
> Cc: Paul Eggert; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
[EMAIL PROTECTED]
--------------------------------------------
