bootstrap/autogen.sh and git submodules

[Bruno Haible <bruno@clisp.org>]

Hi,

When gnulib is used in a package, often the maintainers of that package
use it via a git submodule, because that enables them to upgrade to newer
versions of gnulib when they want to (and have a failsafe build between
these upgrades), rather than having to adapt to gnulib changes at any moment.
Even if it's only the imported file list which has changed, which might
require an update to the package's .gitignore file.

The use of git submodules, however, has three problems:

  1) There are two use-cases of bootstrap/autogen.sh (the name does not matter):
       - first-time checkout and build of the sources,
       - repeated build, possibly after modifying something in the submodule.
     Currently bootstrap is optimized for the first one, and requires clumsy
     recipes for the second one. Such as:
       $ GNULIB_SRCDIR=`pwd`/gnulib ./autogen.sh --no-git

  2) A submodule has to be upgraded occasionally. bootstrap/autogen.sh does
     not help doing this. I have to keep a command in a cheat-sheet:
       $ (cd gnulib && git fetch && git merge origin/master); git add gnulib

  3) As can be seen in the recent thread, there is considerable disagreement
     regarding the handling of git submodules. Akim wants a fatal error when
     some git submodules have not been initialized, whereas Tim hates this.

I would propose to split the common bootstrap or autogen.sh into two
programs that can be invoked independently:

  1. A program that deals only with the git submodules.
  2. A program that only generates files (or, regarding PO files, fetches
     files that are not kept in git).

The developer should have the ability to set an environment variable
(GNULIB_SRCDIR or GNULIB_TOOL), to be used by both programs.

Advantages:
  - Developers can test modified gnulib sources without running through
    hoops.
  - Developers will have an easy way to upgrade to a newer gnulib version.
  - Different project policies regarding submodules are isolated in one place
    and thus have no influence on the gnulib-tool invocation, the PO file
    handling, etc.

Disadvantages:
  - The README-HACKING file will have to list two commands instead of one,
    for the first-time checkout.

What's your opinion?

I'd like to hear your voices, before I modify the autogen.sh scripts that
I maintain. I won't touch 'bootstrap' (not my domain).

Bruno