Currently README-hacking suggests using GNULIB_SRCDIR to clone a Gnulib submodule with 'git clone --reference'. This used to be the case but changed in 2022 [1].
Nowadays, GNULIB_SRCDIR still exists but ./bootstrap will just use that directory instead of using the submodule at all. I sometimes use this to test Coreutils with newer Gnulib commits because I struggle to remember git submodule commands. However, if someone has an older Gnulib checkout ./bootstrap will almost certainly fail due to missing files, for example, which may be confusing. Therefore, I think we should recommend GNULIB_REFDIR since it will always create a submodule and checkout the proper Gnulib commit that Coreutils specifies. Collin [1] https://github.com/coreutils/gnulib/commit/2122284380cc0d1b3b6f11d92c04652616da79c7
>From 790d6677f2bb9e1304ffe41180194283e65954ee Mon Sep 17 00:00:00 2001 From: Collin Funk <collin.fu...@gmail.com> Date: Sun, 11 May 2025 10:07:22 -0700 Subject: [PATCH] doc: Suggest GNULIB_REFDIR instead of GNULIB_SRCDIR * README-hacking: Use GNULIB_REFDIR instead of GNULIB_SRCDIR since that is the correct way to have ./bootstrap do 'git clone --reference'. --- README-hacking | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README-hacking b/README-hacking index 17e548edc..c6529ac2c 100644 --- a/README-hacking +++ b/README-hacking @@ -43,7 +43,7 @@ As an optional step, if you already have a copy of the Gnulib Git repository, then you can use it as a reference to reduce download time and file system space requirements: - $ export GNULIB_SRCDIR=/path/to/gnulib + $ export GNULIB_REFDIR=/path/to/gnulib The next steps are to get and check other files needed to build, and complete the build: -- 2.49.0
