Hello Reuben,
> Using macros
> from autoconf-archive is fairly straightforward, but it seems to me
> they could benefit from being merged into gnulib, one ax_foo gnulib
> module per ax_foo autoconf-archive macro.
It is true that gnulib and autoconf-archive are similar in the sense
that both of them provide source code that gets added to a package
before 'aclocal' and 'autoconf' are run.
There's also 'libtool', in the same camp (through 'libtoolize').
But is this enough of a reason to merge these projects? I think it
would be useful to allow more projects of this kind to use the same
tool for propagating the source code, namely gnulib-tool, extended
1. to allow multiple --local-dir options,
2. to allow fetching source code from git, hg, bzr, or svn servers,
or even from tarballs.
> 1. No need to find out about autoconf-archive separately from gnulib
> (or indeed vice versa!).
The Autoconf documentation contains references to autoconf-archive
already.
> 2. Automatic import of dependencies (autoconf-archive macros would
> list their dependencies on other autoconf-archive macros, which would
> be satisfied by gnulib-tool --import as usual).
If autoconf-archives macros have dependencies that so far have not
been formally stated, then I would encourage them to adopt gnulib's
module description format and hack gnulib-tool to collect the
dependencies automatically.
> 3. Better documentation: autoconf-archive macros' documentation would
> be texinfo in the gnulib manual rather than comments in the autoconf
> files. Easier to read in a variety of formats.
Actually the major problem in the autoconf-archive is probably not
its format, but that it does not state what the macro provides or
fixes. For example, ax_func_fork.m4 does not state against which
kind of problem it checks - given that gnulib's doc/posix-functions/fork.texi
does not mention any known problems of fork(). Or ax_openmp.m4 does
not state how it compares to AC_OPENMP.
> 5. No need to commit autoconf-archive macros to my git repos.
You don't need to have fetched files committed in version control;
just change your 'autogen.sh' or 'bootstrap' script to fetch the
macros from the autoconf-archive repository on the web. That is,
use 'wget' commands like you use gnulib-tool.
> I see one disadvantage: the gnulib maintainers might not be happy to
> give all autoconf-archive maintainers commit access to gnulib.
More generally, different projects have different guidelines, and it
would be bad to force one project's philosophy on the other.
- gnulib wants to present "generally useful" things, whereas
autoconf-archive is more about "occasionally useful". For example,
gnulib has no macro for linking with libncurses, because different
programs have different expectations regarding what they expect
from the curses library.
- gnulib provides something ready-to-use, by combining .m4 and .c
code together. autoconf-archive often provides lower-level building
bricks, see e.g. ax_snprintf_oflow.m4 which simply defines
HAVE_SNPRINTF_BUG, while gnulib would provide a corrected snprintf
function.
Bruno
--
In memoriam Erich Fellgiebel <http://en.wikipedia.org/wiki/Erich_Fellgiebel>
