Re: issues with git submodules and `bootstrap'

[Gary V. Vaughan]

Hi Werner,

On 11 Jan 2012, at 12:30, Werner LEMBERG wrote:
>>>> After doing the incantation described in section 2.8 of gnulib.pdf,
>>>> namely
>>>> 
>>>>  $ dir=.gnulib
>>>>  $ git submodule add -- git://git.sv.gnu.org/gnulib.git $dir
>>>> 
>>>> the user has to commit the submodule setup to the repository.  It's
>>>> probably worth to mention this.
>>>> 
>>>> However, if I now say `git config --file .gitmodules --list' (I
>>>> haven't touched the data within `.gitmodules'), I see
>>>> 
>>>>  submodule..gnulib.path=.gnulib
>>>>  submodule..gnulib.url=git://git.sv.gnu.org/gnulib.git
>>>> 
>>>> Note the double dot.  Interestingly, the name of the submodule is
>>>> taken from the directory location, not the repository name.  Maybe a
>>>> git bug?  I'm using version 1.7.8.
>>> 
>>> According to a google search, this is a feature.
>> 
>> Odd.
> 
> After some thinking I now believe that the creation of a gnulib
> submodule even for the first user (this is, if no `.gitmodules' file
> exist yet in the repository) must be handled by `bootstrap'.  The
> steps described in gnulib.info, even if I pretend that the description
> is correct and complete, are too complicated and error-prone IMHO.  An
> additional difficulty is that git currently lacks a `git submodule rm'
> command...  It really took me a long time to fix everything.

Yes, I agree.

When I first tried to move GNU M4 from it's own bespoke bootstrap to the
gnulib version, I had all kinds of similar trouble, and then when Libtool
began moving towards using more of gnulib I didn't want to go through all
that pain again which is part of why I decided to rewrite the bootstrap
from scratch (bouyed by the encouragement from the gnulib maintainers) -
the other reason being that it is pretty difficult to extend the gnulib
bootstrap cleanly, and libtool's bootstrap is very non-standard.  With my
rewritten bootstrap, even libtool's torturous multi-level bootstrap process
is a simple matter of registering a few hook functions, rather than having
to override some of the internals as was required by the gnulib version.

> I haven't tried yet but a quick look into the code seems to confirm
> that Gary's `bootstrap' file can do that.  In case this is true I
> really recommend to use his version as the default in gnulib.

I agree with this too :)

However, I understand that reviewing a few thousand lines of new shell
code (even though heavily inspired by the bootstrap and bootstrap.conf
scripts of several prominent GNU projects) is no easy task.  On the last
round of discussions, I promised to submit the contents a few dozen lines
at a time for review and hopeful acceptance as a replacement for the
existing script.

Since then, I've broken out some functionality into reusable standalone
scripts that will be useful for replacing the hairy sed-and-grep method
of interrogating the m4 macros used by configure.ac with a much more
robust and faster call to parse the m4 macros with GNU M4!  I'll submit
that script presently, and the hook-and-require infrastructure file it
depends on.  If we can agree on accepting those into upstream, I'll start
posting the bootstrap rewrite contents for review a few functions at a
time.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)