bug#62099: 29.0.60; Intentional change to *Help* source code links?

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 62099@debbugs.gnu.org,  larsi@gnus.org
> Date: Sun, 14 May 2023 18:18:59 +0200
> 
> > Well, if you could find out the offending code, it will be
> > appreciated.
> 
> 43b0210f83c only changed how loaddefs.el is generated, and for
> out-of-tree builds, also how the names of the files under lisp are
> represented in loaddefs.el.  Prior to the change, in out-of-tree builds
> these file names appeared the same as those in in-tree builds, e.g.:
> 
> ;;; Generated autoloads from play/5x5.el
> 
> But after 43b0210f83c, in my out-of-tree builds, they now look like
> this:
> 
> ;;; Generated autoloads from 
> ../../../../../../home/steve/src/emacs/test-29/lisp/play/5x5.el

Isn't the above difference the root cause, right there?  Why should
the output in loaddefs.el depend on whether this is an in-tree or
out-of-tree build?  Eventually, when the produced loaddefs.el is
installed, the *.el files from the tree and the *.elc files from both
the tree and out-of-tree will end up in the same directory, so there
should be no ../../../..  etc. in the file names recorded in
loaddefs.el, they should be all relative to <source-directory>/lisp,
no?  It seems like loaddefs-gen.el does this instead:

            (let* ((relfile (file-relative-name
                             (cadar section)
                             (file-name-directory loaddefs-file)))
                   (head (concat "\n\f\n;;; Generated autoloads from "
                                 relfile "\n\n")))

which uses the wrong directory as the second arg of
file-relative-name.

Am I missing something?

Or maybe step through the code in autoloads.el and see how it succeeds
in computing the correct relative file name even in out-of-tree
builds, and let's take it from there.

> I traced the problematic appearance of links in *Help* through the call
> chain describe-function -> describe-function-1 ->
> help-fns-function-description-header -> find-lisp-object-file-name ->
> symbol-file, and symbol-file gets the file name from load-history.  In a
> fresh Emacs, started with a triggering init file, load-history contains
> only standard absolute file names, but when I type `C-h f' and then
> evaluate load-history again, it now contains problematic files names
> like "/../home/steve/src/emacs/test-29/lisp/help-fns.elc".  I set a
> breakpoint in gdb on build_load_history, but when I hit it after typing
> `C-h f' and started stepping through the function, the first opportunity
> I had to evaluate its argument `filename' already showed the problematic
> form.  Then I set a breakpoint on readevalloop, the caller of
> build_load_history in lread.c, but again, the first opportunity I had to
> evaluate readevalloop's argument `sourcename', which is passed to
> build_load_history, already showed the problematic form.  I don't know
> where else to look to try and find out how such forms get into
> load-history.

It is possible that these are computed by temacs as part of the build,
so the dumped Emacs gets them already cooked.

However, I think we should concentrate on the first place with the
deviation, which I think is loaddefs.el.