Re: [Groff] preconv autoconfigury

[Keith MARSHALL]

Bruno Haible wrote, quoting me:
>> Having segregated the m4 files, you then use aclocal to reassemble
>> them into aclocal.m4.
>
> You will notice that after running 'aclocal -I m4', the aclocal.m4
> file contains symbolic references to the various *.m4 files, not
> their contents. (Assuming you are using the automake-1.9.x tools.)

I don't use *any* version of automake, (and I fervently hope that
Werner will never take groff down this route).  The current problem
with aclocal is that it is a tool distributed with automake, yet its
value seems more applicable to use with autoconf.

>> Current wisdom from the autoconf mailing
>> list would suggest that aclocal, as a configuration tool, should
>> be considered as deprecated.
>
> If it's deprecated, then what is its replacement?

For me it is, and always has been vim :-)  OTOH, where it is known
that *all* files in a specified m4 subdiriectory are to be subsumed
into aclocal.m4, a combination of ls, or even echo, with either sed
or awk should suffice.

> As far as I know, there is agreement that future versions of autoconf
> and automake could get away without a tool that just collects a list
> of filenames and creates a file from it.  But the latest releases of
> autoconf and automake still need 'aclocal'.
>
>> Is it really appropriate to start
>> using it within groff's build system, at this late point in time?
>
> groff's current build system doesn't yet use automake. Do you know
> whether the replacement of 'aclocal' will work with just 'autoconf'?
> Or will it rely on both autoconf and automake? I don't know.

I don't either.  It just seems strange that an autoconf managed project,
which does not use automake, should rely on a tool which is distributed
only with automake.

Regards,
Keith.