Re: [gnugo-devel] autotools

[Yllman, Jens (NEVERUSE)]

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

address@hidden 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