Re: bootstrap and git submodules

[Eric Blake]

On 03/14/2010 07:54 AM, Bruno Haible wrote:
>   * There are five use cases of the 'bootstrap' script:
>       1) A normal user who wants to check out coreutils with the version
>          of gnulib with which it was tested. Does not want to be bothered
>          with versions, what gnulib is in the first place, etc.
>       2) Like 1), but the user knows what gnulib is and has a copy of it
>          on his disk.

Yes, bootstrap is good for these two.

>       3) An expert user who wants to check out the latest gnulib,
>          regardless what it contains. He is prepared to report errors.
>       4) Like 2), and he has a copy of gnulib on his disk.

Here, the recommendation in coreutils and libvirt is to create an alias,
and call 'git syncsub' to update all submodules to their latest upstream
version.  If that is good, then commit the result and push it upstream
in the parent project.

My current procedures on m4 are:

$ git syncsub # with this being an alias documented in HACKING
$ gnulib/gnulib-tool --update
$ make check
$ git add gnulib
$ git commit

or in coreutils:

$ git syncsub
$ git add gnulib
$ ./bootstrap
$ make check
$ git commit

So providing a single gnulib-tool or bootstrap option that can
consolidate some of these steps into a single step might prove useful.

>       5) An expert user who wants to use his modified version of gnulib.

Not much different than 4.  Rather than syncing to the latest upstream,
you instead sync to the latest state of your modified repo.

>     The option --gnulib-srcdir was for use case 5 in the past, IIRC.

For build-aux/bootstrap, yes, but it was accidental and not intentional.
 Before that, it was ALSO used for 2.  But for m4, it has always been
for number 2, and for several years now.

> So, I think 'bootstrap' needs 3 command line options:
>   - One option for choosing use case 3. I propose --gnulib-newest.
>   - One option for choosing use cases 2 or 4, from 1 or 3. I propose to call
>     it --gnulib-repodir.

I'd much rather keep the name --gnulib-srcdir here, to match the
environment variable (mainly because I don't want to modify the
environment variable for projects like m4 that don't use
build-aux/bootstrap, but which HAVE used the envvar GNULIB_SRCDIR for
several years now).

>   - One option for choosing use case 5. The name --gnulib-srcdir seems to be
>     the right one for this. (As it was before 2008.)

Which means maybe a better name for this proposed option would be
--gnulib-upstream, which can be used like:

--gnulib-upstream=git://git.sv.gnu.org/gnulib.git

or
--gnulib-upstream=/path/to/modified/gnulib

> 
> Here is a proposed patch. Tested in all five cases.

I'd like to hear other's opinions before this gets committed,
particularly since I am not the primary maintainer on any project that
actually uses build-aux/bootstrap.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature