[Bug-gnulib] making it easier to import from gnulib

[Bruno Haible]

Hi all,

Currently it is quite error-prone to use a module from gnulib. The
following problems have arisen:

  1) Someone imports a file into his package and it not aware that
     it depends on other files. Seen in findutils, where the
     maintainer took lib/strtoul.c but forgot lib/strtol.c. On
     most platforms it compiles fine! But on platforms without
     strtoul, of course, compilation fails.

  2) Not all prerequisites of the module are invoked by configure.in.
     Most often this is because the module doesn't have an explicit
     autoconf macro for this purpose. Or sometimes it has one, but
     it is incomplete.

  3) Use of AC_LIBOBJ for a module which is meant to be compiled
     unconditionally. Seen in sharutils.

As a consequence, gnulib does not deliver the promise of increased
portability: After importing a module, the maintainer still has to
test his package on a plethora of platforms in order to detect
portability problems.

The reasons for this are clear:

  1) There is no formal dependency list for the modules. The fourth
     column in MODULES.txt is a first step in solving this issue.

  2) The third column of MODULES.txt consists of more than one
     macro call, for most modules.

  3) The necessary modifications to configure.ac and lib/Makefile.am
     are not written down anywhere.

In order to fix these problems I'd like, over the next few weeks, to
undertake the following steps:

   * Formalize the module notion: Create a file list named
     modules/<module>.list for each module.

   * Formalize the module dependencies: Create a depencency list
     named modules/<module>.dep for each module that has dependencies.

   * Simplify the third column of MODULES.txt by creating a file
     named m4/<module>.m4 containing the necessary autoconf macro(s).
     The name of the autoconf macro, if it already exists, is kept
     unchanged.

   * Add a one-liner file m4/<module>.ac for each module, containing
     the name of the autoconf macro to be called from configure.ac.

   * Add a tiny file lib/<module>.am for each module, describing the
     way the Makefile.am needs to be modified for the module. For
     most modules, it will be a one-liner, however for 'localcharset'
     and 'stdbool' it will be more.

The idea of this infrastructure is _not_ to be copied into a package
that uses gnulib modules (only the *.m4 files will end up copied).
Rather, I propose a tool

   * gnulibize.
     When called as "gnulibize <module1> ... <moduleN>" it
     adds/updates a package's configure.ac & lib/Makefile.am & m4/*
     & lib/* accordingly. All the info it needs is taken from the
     file lists, dependency lists, and *.ac and *.am files.

This tool will also be essential in testing the *.m4 changes that
I want to make. The idea is to create a testing directory for each
module, call gnulibize there, and try to compile the resulting
complete project on a dozen of platforms:

     for module in $MODULES; do
       mkdir test/$module
       cd test/$module && {
         gnulibize $module
         aclocal
         autoconf
         automake
       }
     done
     make dist
     remote-test $SOLARIS_HOST
     remote-test $AIX_HOST
     remote-test $OSF1_HOST
     etc.


Comments?

What is the minimum version of autoconf that I should care about? Is
2.57 OK for everyone?

Bruno