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

[Stephen Berman]

On Sun, 14 May 2023 20:41:20 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> 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?

I'm not sure I understand: there are no *.elc files in the out-of-tree
build directory, all byte-compiled files reside in the source tree
together with the *.el files.  Also, FWIW I do not install my Emacs
builds and haven't tested whether the problematic file names appear in
an installed build.

>      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?

Well, for one thing this part of the code was not touched by
43b0210f83c.  Also, while I haven't found a way to step through
loaddefs-generate while loaddefs.el is being generated, since that's
part of the build process, note that evaluating the following sexp:

(file-relative-name "/datadisk/steve/src/emacs/test-29/lisp/play/5x5.el" 
"~/build/test-29/lisp/play")

produces the same number of "../" as appear in loaddefs.el:

"../../../../../../datadisk/steve/src/emacs/test-29/lisp/play/5x5.el"

The difference is that loaddefs.el has "home" instead of "datadisk".
But on my system, ~/src is a symlink to /datadisk/steve/src.  Perhaps
this an irrelevant coincidence, but I found it striking in this context.

> 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.

Do you mean autoload.el?  But this file was obsoleted in commit
22a2ad13f50 not long after commit 43b0210f83c and I believe
loaddefs-gen.el is meant to be its replacement.

>> 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.

I don't think this can be the case, since the problematic file names do
not show up in load-history when Emacs is started with -Q but only when
started with a triggering init file, and it's the same temacs in both
cases.

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

I'm not sure: it seems to me those file names with "../../../../../../"
are intended, in order, as the commit message of 43b0210f83c says, to
"Fix out-of-tree build problems with loaddefs.el".  I don't remember if
the discussion in emacs-devel leading up to that commit clarifies the
matter; I need to read through it again.

Steve Berman