Package: emacs;
Reported by: Stephen Berman <stephen.berman <at> gmx.net>
Date: Fri, 10 Mar 2023 17:11:02 UTC
Severity: minor
Found in version 29.0.60
Message #29 received at 62099 <at> debbugs.gnu.org (full text, mbox):
From: Stephen Berman <stephen.berman <at> gmx.net> To: Eli Zaretskii <eliz <at> gnu.org> Cc: larsi <at> gnus.org, 62099 <at> debbugs.gnu.org Subject: Re: bug#62099: 29.0.60; Intentional change to *Help* source code links? Date: Mon, 15 May 2023 01:11:05 +0200
On Sun, 14 May 2023 20:41:20 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote: >> From: Stephen Berman <stephen.berman <at> gmx.net> >> Cc: 62099 <at> debbugs.gnu.org, larsi <at> 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
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.