autoreconf is only a tool that run aclocal/autoconf/automake/etc to create all the files needed. The -f parameter is to force a rebuild of all.
>From some version of autoconf it is now called configure.ac instead of configure.in. It is still OK to have configure.in. And many of the old macros are still valid to. But there are newer versions of many macros that might be better to use. But maybe not necessary to change to right now. Running autoscan can be a way to get the basic idee of how the base of configure.ac could look in gnugo-project. But not to get all the different checks that is done in configure.in in gnugo. Only the basic that goes for the standard tools/headers/functions/etc. AC_INIT() now takes some of the parameters that used to be in AM_INIT_AUTOMAKE(), and AM_INIT_AUTOMAKE() only takes parameters for how automake acts, like if it is strict gnu project or more loose. autoscan does note include AM_INIT_AUTOMAKE() in its output. This is only speculation, .am in Makefile.am is logically connected to automake. .ac in configure.ac looks better then .in configure.in. Also, automake creates Makefile.in from Makefile.am, that kind of gets confusing with configure.in. So I guess that is why the change to configure.ac. Today I think the autotools come with more then one version of automake and autoconf. You can run the version you want by running automake-1.9. And automake is only link to the latest version. Jens [EMAIL PROTECTED] wrote: > Jens Yllman wroe: > >> autoreconf -f should force rebuild of all files needed buy autoconf/automake. >> I have not yet verified that it copies/recreates aclocal.m4. But I think it >> should. > > The patch includes new Automake.in in every directory, new aclocal.m4 and > new configure. I didn't use your method produce aclocal.m4 but > just ran /usr/bin/aclocal-1.9 which creates the file. > >> Have you changed in configure.ac to require these versions of >> automake/autoconf? > > There is no configure.ac in GNU Go. > > I believe that configure.in may require some further editing but > Gunnar did some testing and didn't find the problems I predicted > (based on memory of what happened the last time we tried to do > this). If anyone wants to look at our configure.in that would > be welcome. > > Dan _______________________________________________ gnugo-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnugo-devel
