On Sat, Jun 11, 2011 at 2:17 PM, Bruno Haible <br...@clisp.org> wrote:
> Hi James,
>
>> + * build-aux/bootstrap: obey the --no-git option.
>
> The --no-git option already has a certain effect; it's not entirely unused.
> How does your change relate to the previously posted patches?
Without this patch, at HEAD, gnulib-tool is always run from
gnulib/gnulib-tool. There's no way to have it run from
${GNULIB_SRCDIR}/gnulib-tool. Perhaps this bug was introduced with a
change in the way we use submodules.
> <http://lists.gnu.org/archive/html/bug-gnulib/2010-03/msg00165.html>
That mail includes no patch. But it describes a method for doing use
case (3). It works before and after this patch, I think (though I
didn't test this, precisely).
> <http://lists.gnu.org/archive/html/bug-gnulib/2010-03/msg00244.html>
In this message, Dmitry mentions "Now git_modules_config is called
unconditionally, even in case
when its result (gnulib_path variable) is not used later." The patch
I posted fixes this problem.
> <http://lists.gnu.org/archive/html/bug-gnulib/2010-06/msg00002.html>
The patch still allows the user to set GNULIB_SRCDIR and have a module
used as a reference in the absence of --no-git, because there is no
change in behaviour when --no-git isn't specified on the command line.
> <http://lists.gnu.org/archive/html/bug-gnulib/2010-06/msg00003.html>
I'm not sure what the intended meaning of this mail is. The (apparent
lack of) difference between use cases 2 and 4 is discussed below.
> <http://lists.gnu.org/archive/html/bug-gnulib/2010-08/msg00047.html>
Contrary what is indicated in this email, gnulib-tool, at HEAD, still
runs git when the user specifies --no-git. Perhaps this is due to a
subsequently-introduced change.
> <http://lists.gnu.org/archive/html/bug-gnulib/2011-01/msg00303.html>
My patch above doesn't touch the same lines as Eric mentions he changed.
> Are all five use-cases from
> <http://lists.gnu.org/archive/html/bug-gnulib/2010-03/msg00135.html>
> covered now?
I'm going to quote those here in the hope of greater clarity.
"""
* 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.
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.
5) An expert user who wants to use his modified version of gnulib.
"""
To enumerate what the user would need to do for each:
1. unset GNULIB_SRCDIR; ./bootstrap
2. Depending on how the user wants to use their local copy of gnulib:
[a] ./bootstrap --gnulib-srcdir=/src/gnulib # uses /src/gnulib as
reference, as before this patch, but use the as-tested version of
gnulib.
[b] unset GNULIB_SRCDIR; ./bootstrap # ignores the local copy of gnulib
3.
# Clearly, updating gnulib in the submodule will do this.
# Other than that, you will need the patch I mailed to do this:
cd /src/
git checkout ${gnulib_url}
git checkout ${coreutils_url} # for example
cd /src/coreutils
./bootstrap --gnulib-srcdir=/src/gnulib --no-git
4. As far as I can tell, this is
"""Like 2), and he has a copy of gnulib on his disk."""
which means,,
"""Like 1), but the user knows what gnulib is and has a copy of it on
his disk, and he has a copy of gnulib on his disk."""
(that is, the qualification introduced in the description of (2) is redundant.)
Perhaps I misinterpreted the indented meaning of this use case.
5. There are multiple strategies. Here are a couple of useful ones:
[a] Use a separate tree:
cd /src/
git checkout ${gnulib_url} ; cd gnulib
git checkout -b my_local_changes master
emacs
# commit or not, it doesn't matter.
cd /src
git checkout ${coreutils_url} # for example
cd coreutils
./bootstrap --gnulib-srcdir=/src/gnulib --no-git
[b] I think it also works to use the submodule:
cd /src
git checkout ${coreutils_url} # for example
cd coreutils
unset GNULIB_SRCDIR
./bootstrap # sets up the submodule
cd gnulib
git checkout -b my_local_changes master
emacs
dit add ...; git commit # both optional I think
cd ..
# bootstrap again if appropriate (e.g. when adding/deleting a module)
./configure && make
So to answer your question, if I understood use case (4) correctly,
all five use cases are now covered.
James.
