new module 'libtool'?

[Bruno Haible]

Hi,

Sam Steingold suggests to create a new gnulib module that would contain the
files
   m4/libtool.m4
   build-aux/ltmain.sh

As with the gettext macros, it is expected that these files get updated in
gnulib after every libtool release (or possibly more frequently, at the
discretion of the libtool maintainers).

Benefits:

  - Package maintainers (like Sam for clisp, or me for gettext and libiconv)
    don't need to actively look for new libtool releases and commit the new
    files into their CVS. Just re-run gnulib-tool. It does it.

  - Package maintainers can more easily track local modifications to libtool.m4,
    by use of gnulib-tool's --local-dir option. (For example, the copy of
    libtool.m4 I use has support for the Comeau C++ compiler.)

  - Often package maintainers don't want to include libtool.m4 into their
    CVS, due to its size. But they do include ltmain.sh. So when the user
    has a different version of libtool installed, he is mixing a libtool.m4
    with an ltmain.sh from a different libtool version. As we all know,
    this leads to trouble (remember $SED). Use of gnulib-tool avoids this
    problem. (Use of libtoolize would also avoid the problem. But when
    gnulib-tool is used anyway, it's easier to include libtool in the list
    of modules, than to add an invocation of libtoolize.)

  - The libtool maintainers may distribute modifications to a smaller
    audience without needing to make a release for the entire audience.
    (gnulib users act as beta testers.)

Dangers:

  - libtoolize is cannibalized. Possible confusion in autoreconf?

  - Someday people will also want to add the entire libltdl to gnulib; is this
    desirable?

Comments?

Bruno