According to Daniel Veillard on 1/25/2010 6:29 AM:
> diff --git a/configure.in b/configure.ac
Sorry for being ignorant but what's the interest of renaming ? what
does that change in practice ?
Conceptually, modern autoconf reserves the namespace *.in for template
files that are fed to config.status to create the substituted files; but
configure.in does not fit that paradigm (configure.in is not processed by
config.status to generate configure). Using the name configure.ac gives a
better indication of what tool is used in processing the file (comparable
to Makefile.am processed by automake, which generates Makefile.in
processed by config.status, which generates Makefile to be processed by
make). Pragmatically, the renaming gets us one step closer to being able
to run 'autoconf -Wall -Werror' as a way to check for other portability
problems in configure.ac (although there are still a number of other
things to address before -Werror will reliably work; in particular, gnulib
still triggers some autoconf warnings for its use of obsolete macros).
> -AM_CONFIG_HEADER([config.h])
> +AC_CONFIG_HEADERS([config.h])
> dnl Make automake keep quiet about wildcards & other GNUmake-isms
> AM_INIT_AUTOMAKE([-Wno-portability])
Independantly of renaming, that looks fine to me,
I don't have commit rights; would someone like to take over from here?
--
Don't work too hard, make some time for fun as well!
Eric Blake ebb9(a)byu.net