From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62099: 29.0.60; Intentional change to *Help* source code links? Date: Sun, 14 May 2023 20:41:20 +0300 Message-ID: <83lehqu7y7.fsf@gnu.org> References: <87pm9gv8fa.fsf@gmx.net> <83sfebwkqv.fsf@gnu.org> <87edpvihw5.fsf@gmx.net> <87ednmmuyq.fsf@gmx.net> <83o7mq3xnp.fsf@gnu.org> <87353yc2do.fsf@gmx.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35155"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 62099@debbugs.gnu.org To: Stephen Berman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun May 14 19:42:23 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pyFjj-0008vw-52 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 14 May 2023 19:42:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pyFjT-0003n5-FU; Sun, 14 May 2023 13:42:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pyFjQ-0003mv-Jm for bug-gnu-emacs@gnu.org; Sun, 14 May 2023 13:42:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pyFjP-0003Aw-2Y for bug-gnu-emacs@gnu.org; Sun, 14 May 2023 13:42:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pyFjO-0001e3-Hs for bug-gnu-emacs@gnu.org; Sun, 14 May 2023 13:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 14 May 2023 17:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62099 X-GNU-PR-Package: emacs Original-Received: via spool by 62099-submit@debbugs.gnu.org id=B62099.16840860876279 (code B ref 62099); Sun, 14 May 2023 17:42:02 +0000 Original-Received: (at 62099) by debbugs.gnu.org; 14 May 2023 17:41:27 +0000 Original-Received: from localhost ([127.0.0.1]:41398 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pyFio-0001dD-PC for submit@debbugs.gnu.org; Sun, 14 May 2023 13:41:27 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:50144) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pyFim-0001d1-OH for 62099@debbugs.gnu.org; Sun, 14 May 2023 13:41:25 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pyFih-00035P-49; Sun, 14 May 2023 13:41:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=26a68WhjzzS/O2JCfoODhBw1EppLxO1w6n13sJRD8jg=; b=QCEsz72owBGQ 04kAuDKddCipoLxvQLLDzj2s4tGJUY3Q9jyLkvvjGfPNHS8LKqD9C8F+8sj29/Hh/h2LlZf/zXCHK EOUvEBC8LPMtmcvzVk9L5gEUR6onDEQMjAAUmNBc6iH7QIOXw/U5KqdWKjNegQyt6wW8kzSP4Esn/ yBnYgjJjWR37B9OBxdfGRDd47YrMRTfFgTWdsOr4HZVYaYA87B4UGyd61d56stdEkMkWfrMW/3qyl A0M+V6f/YDUhTQJI0p/mji2HyLBTd/j3pVJCX3M0VYrzEpEd8qDp5U2yYG6FRkVUvTWy59CydPkgY tNKURnnyWIFQgOeF6D5+UQ==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pyFig-0005Sl-JV; Sun, 14 May 2023 13:41:18 -0400 In-Reply-To: <87353yc2do.fsf@gmx.net> (message from Stephen Berman on Sun, 14 May 2023 18:18:59 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:261716 Archived-At: > From: Stephen Berman > 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 /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.