bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Merge autoconf-archive into gnulib?


From: Bruno Haible
Subject: Re: Merge autoconf-archive into gnulib?
Date: Mon, 5 Sep 2011 01:43:47 +0200
User-agent: KMail/1.13.6 (Linux/2.6.37.6-0.5-desktop; KDE/4.6.0; x86_64; ; )

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>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]