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@xxxxxxx -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list