[autoconf-conversion] Something to start with

[Bonzini]

> There are varying levels of conversion we could do.  For instance,
> "proper" autoconf 2.5x style looks quite different from 2.13 style.
> I didn't try to do this.

I think it should be good to move the arguments from AC_INIT to AC_CONFIG_SRCDIR, from
AM_INIT_AUTOMAKE to AC_INIT and from AC_OUTPUT to AC_CONFIG_FILES, and renaming
AC_CONFIG_HEADER to AC_CONFIG_HEADERS.  But this can be done at the end.

> In a similar vein I added "1.6" to AUTOMAKE_OPTIONS, to prevent use of
> earlier versions (I would have used 1.7 but at the moment 1.6 was
> easier for me to access).  While 1.7 isn't shipped in RHL 9, I still
> think we should require it and not 1.6.  1.7 has had a lot of bug
> fixing, plus other enhancements which may actually be useful (in
> places).

I agree.  For example, it avoids exponential explosion in the idiom

if COND1
VAR += VALUE1
endif
if COND2
VAR += VALUE2
endif
if COND3
VAR += VALUE3
endif

which might be useful for some Makefile.am's such as libffi's.  I hope to post a patch
for libffi on Tuesday, and maybe libjava too.

zlib should be ready as is, except for removing the three lines that mention AC_EXEEXT.
Some comments in it refer to Autoconf 2.5x so it looks like it was "multi-versioned".

Also, it might be interesting to move AC_PROG_LIBTOOL to the toplevel.  Configuring
libtool takes a little while.  But probably it would only be feasible after
bootstrapping is moved there as well.  Take note.

I think it would be best to post the patch versus configure.in, and then actually
"rename" it to configure.ac at commit time.  Review would be much easier.

> I chose to enable automake's dependency tracking.  I think this is
> reasonable, but as it may be troublesome I thought I'd point it out
> explicitly.  I'm happy to share my perspective on the benefits and
> tradeoffs if anybody wants.

In 1.7 it should not be troublesome at all (dependencies are generated at compilation
time, and anyway there's --disable-dependency-tracking -- you will know better than me,
but other people might not :-).

Paolo