[PATCH] bootstrap: allow non-submodule control of gnulib

[Colin Watson]

Some projects prefer to avoid git submodules for various reasons (they
have rather strange UI), but at present they're the only way to pin a
particular gnulib commit. Add a couple of extra variables which can be
set in bootstrap.conf to control this separately.

* build-aux/bootstrap: Honour GNULIB_URL and GNULIB_REVISION in
bootstrap.conf when fetching gnulib using "git clone" or via
GNULIB_SRCDIR.

Signed-off-by: Colin Watson <***@debian.org>
---
build-aux/bootstrap | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/build-aux/bootstrap b/build-aux/bootstrap
index 92be11439..b5d000370 100755
--- a/build-aux/bootstrap
+++ b/build-aux/bootstrap
@@ -634,9 +634,11 @@ case ${GNULIB_SRCDIR--} in
trap cleanup_gnulib 1 2 13 15

shallow=
- git clone -h 2>&1 | grep -- --depth > /dev/null && shallow='--depth 2'
- git clone $shallow git://git.sv.gnu.org/gnulib "$gnulib_path" ||
- cleanup_gnulib
+ if test -z "$GNULIB_REVISION"; then
+ git clone -h 2>&1 | grep -- --depth > /dev/null && shallow='--depth 2'
+ fi
+ git clone $shallow ${GNULIB_URL:-git://git.sv.gnu.org/gnulib} \
+ "$gnulib_path" || cleanup_gnulib

trap - 1 2 13 15
fi
@@ -671,6 +673,11 @@ case ${GNULIB_SRCDIR--} in
;;
esac

+if test -d "$GNULIB_SRCDIR"/.git && test -n "$GNULIB_REVISION" && \
+ ! git_modules_config submodule.gnulib.url >/dev/null; then
+ (cd "$GNULIB_SRCDIR" && git checkout "$GNULIB_REVISION") || cleanup_gnulib
+fi
+
# $GNULIB_SRCDIR now points to the version of gnulib to use, and
# we no longer need to use git or $gnulib_path below here.

[Bruno Haible]

Hi Colin,

Post by Colin Watson
Some projects prefer to avoid git submodules for various reasons (they
have rather strange UI), but at present they're the only way to pin a
particular gnulib commit. Add a couple of extra variables which can be
set in bootstrap.conf to control this separately.
* build-aux/bootstrap: Honour GNULIB_URL and GNULIB_REVISION in
bootstrap.conf when fetching gnulib using "git clone" or via
GNULIB_SRCDIR.

With this change, the question "Which command-line options should I pass
to 'bootstrap', and which environment variables should I set before
invoking bootstrap?" has more than a single-sentence answer.

Since we don't have a bootstrap.texi documentation, I would suggest to
add such documentation to the 'bootstrap --help' output.

This documentation would need to cover
* --no-git
* --gnulib-srcdir
* GNULIB_SRCDIR
* GNULIB_REVISION
* GNULIB_URL
* In which cases is a submodule being created, in which not?

Bruno

[Colin Watson]

Post by Bruno Haible
Hi Colin,

Post by Colin Watson
Some projects prefer to avoid git submodules for various reasons (they
have rather strange UI), but at present they're the only way to pin a
particular gnulib commit. Add a couple of extra variables which can be
set in bootstrap.conf to control this separately.
* build-aux/bootstrap: Honour GNULIB_URL and GNULIB_REVISION in
bootstrap.conf when fetching gnulib using "git clone" or via
GNULIB_SRCDIR.

With this change, the question "Which command-line options should I pass
to 'bootstrap', and which environment variables should I set before
invoking bootstrap?" has more than a single-sentence answer.

I don't understand why that is. These are intended to be variables that
a project can set in bootstrap.conf (the same way that projects in
languages that have package managers often pin particular versions of
their dependencies that they've tested), not command-line options or
environment variables. I intended this to be nothing more than a way to
control the things that you can already control by way of .gitmodules,
except without having to use git submodules with all their little
oddities.

If something I did led you to believe these were intended as
command-line options or as environment variables, then please tell me
what.

The question "Which variables may I set in bootstrap.conf?" already has
much more than a single-sentence answer ...

Thanks,

[Bruno Haible]

Hi Colin,

Post by Colin Watson
These are intended to be variables that
a project can set in bootstrap.conf (the same way that projects in
languages that have package managers often pin particular versions of
their dependencies that they've tested), not command-line options or
environment variables.

Ah, I saw code that tests $GNULIB_REVISION without prior explicit
initialization, so I assumed it would have to be set as an environment
variable. But you're right, it can equally be set in bootstrap.conf
- whichever is more convenient to the project or user.

Post by Colin Watson
I intended this to be nothing more than a way to
control the things that you can already control by way of .gitmodules,
except without having to use git submodules with all their little
oddities.

Yes, this is good.

What I'm saying is that code changes that offer more choice to the user
should be accompanied with documentation changes, so that the user is
aware of the choices that you offer them.

Guessing what are the possible choices, by reading the code, is - as we
just witnessed :-) - a bit hard.

Post by Colin Watson
The question "Which variables may I set in bootstrap.conf?" already has
much more than a single-sentence answer ...

Yes, but now would be the good moment to start documenting it. At least
for the part that affects how gnulib is being fetched/pulled/used.

Bruno