bug#59064: 29.0.50; build problem git worktree linked to main worktree (repo)

[Matt Armstrong]

Gregor Zattler <telegraph@gmx.net> writes:

> Dear Emacs developers,
>
> building Emacs from sources in a detached linked worktree[1]
> linked to a main worktree[1] fails, because necessary
> -by.el, -wy.el files are not generated as described in
> admin/grammars/Makefile for targets `bovine` and `wisent`.
> Instead while these files are generated error messages "Args
> out of range: "master", 0, 7" are shown and the respective
> files are not generated.

These sorts of lisp level "Args out of range" errors during the build
are typical of a need to run "make bootstrap" to rebuild much more than
is usually rebuilt.  With respect to lisp compilation the build system
takes a few short cuts for expediency sake, and sometimes requires this
extra help.

See the INSTALL.REPO file in the root of the git tree for more
information about this.

At the extreme, you can tell git to delete all files not under version
control with this command:

    git clean -dfx

This is what I do when I want to get the tree into the same state it
would be if I deleted it entirely and re-cloned it.


> But I found out that building instead from sources in a
> linked worktree linked to a bare repository[1] works as
> expected.

This may have been because re-cloning the worktree was akin to the git
clean command above?

(however, what you say next raises doubts...)


> In order to rule out any misconfiguration on my side, I installed
> Emacs build dependencies on a minimal installation of Debian/bullseye,
> cloned the emacs git repo with a freshly created and otherwise
> unconfigured user.  To trigger the build process this user then issued
> only "make V=1 -j 1" to get the most default build process.  All tests
> were made with freshly cloned repos respectively freshly generated git
> worktrees created from those pristine git repos.
>
> The difference between a linked worktree and its main
> worktree is in the .git directory only, as this diff shows:
> $ diff -aNurx.git/* emacs2 emacs2-worktree
> File emacs2/.git is a directory while file emacs2-worktree/.git is a regular 
> file

Well that is a pretty compelling argument.

I have just created a fresh worktree from a non-bare git repo using:

    git worktree add ../b59064 scratch/matta/master

The "scratch/matta/master" tree is close to the current "master" branch.

Then in the ../b59064 repository, "cat .git" produces:

    gitdir: /home/matt/git/e/emacs/.git/worktrees/b59064

In this directory a clean build works fine, so I have not yet reproduced
the problem.


> While investigating, I learned that the build process embeds
> the repository revision into the Emacs binary.  This is the
> case if Emacs is build in a linked worktree linked to a bare
> repository, as the template from emacs-report-bug shows.

In my case, the built Emacs successfully above figures out the
repository revision.  For example, this is copied out of the buffer
created by M-x report-emacs-bug:

In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.34, cairo version 1.16.0) of 2022-11-05 built on naz
Repository revision: ce917027c69f77b8dd6eb2052b018593f36a393f
Repository branch: scratch/matta/master
System Description: Debian GNU/Linux bookworm/sid

Configured using:
 'configure 'CFLAGS=-Og -g3' 'CXXFLAGS=-Og -g3' --enable-checking=yes
 --enable-check-lisp-object-type --with-pgtk'


> If you have further specific questions, I'm happy to help as
> far as my very limited knowledge allows.

You reproduced this on a fresh Debian/bullseye system, presumably run in
a VM?  I am on Debian Testing, updated about a week ago.  So that is one
difference.

I think the next thing to do is to figure out if either:

a) This can reproduce this on a Debian/testing or Debian/sid system.  Is
it easy for you to spin up a VM to do this?  If so, it would be useful
to know if this is related to the Debian version, as you are likely to
use steps similar to what you've already done.

b) Whether I can reproduce this on a vanilla Debian/bullseye system,
using steps as you've described.  I'm willing to try this, but I don't
have time to do it today.

...or someone else can reproduce it before either of us get to (a) or (b).