Re: Odd messages during bootstrap

[John W. Eaton]

On 1/27/20 11:18 AM, Rik wrote:
> I know there is a lot of change to the implementation of gnulib in Octave
> just now, but I thought I'd report a scary error message during the
> bootstrap phase.
>
> I'm getting
>
> generating libinterp/dldfcn/module.mk...
> fatal: not a git repository (or any parent up to mount point /)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
> running: AUTOPOINT=true LIBTOOLIZE=true autoreconf --verbose --install
> --force -I m4  --no-recursive
>
> The "fatal" message sounds bad, although bootstrap completes and I am able
> to configure and make Octave.
>
> This is with
>
> changeset:   28016:626ba7cc1d6c
> bookmark:    @
> tag:         tip
> user:        John W. Eaton <address@hidden>
> date:        Mon Jan 27 10:17:06 2020 -0500
> summary:     update bootstrap script with changes from gnulib version
>
> with an external gnulib repository pulled today (1/27/2020).

I think this is happending because I updated to the latest bootstrap 
script from gnulib.  The message is coming from running git submodule" 
and that was added by this commit to gnulib:

  ce6b5cfac8dc60297d433bc868d32469dc06c36d

These lines were added:

diff --git a/build-aux/bootstrap b/build-aux/bootstrap
index c13b486c5..5b08e7e2d 100755
--- a/build-aux/bootstrap
+++ b/build-aux/bootstrap

 bootstrap_post_import_hook \
   || die "bootstrap_post_import_hook failed"

+# Don't proceed if there are uninitialized submodules.  In particular,
+# the next step will remove dangling links, which might be links into
+# uninitialized submodules.
+#
+# Uninitialized submodules are listed with an initial dash.
+if $use_git && git submodule | grep '^-' >/dev/null; then
+  die "some git submodules are not initialized. "     \
+      "Run 'git submodule init' and bootstrap again."
+fi
+
 # Remove any dangling symlink matching "*.m4" or "*.[ch]" in some
 # gnulib-populated directories.  Such .m4 files would cause aclocal to 
fail.
 # The following requires GNU find 4.2.3 or newer.  Considering the usual

I don't know what the proper fix is.  I guess if the top-level directory 
of the project is not a git repo, then we could skip the check for 
gnulib as a submodule even if the gnulib repo is using git.  What's the 
best way to check for that?  Look for a .git directory?  I guess we 
should discuss with the gnulib maintainers.

jwe