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#48117: 28.0.50; Update of loaddefs.el during normal build is unreliable Date: Fri, 30 Apr 2021 18:48:34 +0300 Message-ID: <83im43bwod.fsf@gnu.org> References: <8335v8c7o0.fsf@gnu.org> <2weeer23xj.fsf@fencepost.gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32088"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48117@debbugs.gnu.org To: Glenn Morris Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 30 17:49:36 2021 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 1lcVOa-0008Fr-J0 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Apr 2021 17:49:36 +0200 Original-Received: from localhost ([::1]:60440 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcVOZ-000761-M5 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 30 Apr 2021 11:49:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49530) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lcVO2-00074S-8r for bug-gnu-emacs@gnu.org; Fri, 30 Apr 2021 11:49:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48079) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lcVO2-0000Sq-0f for bug-gnu-emacs@gnu.org; Fri, 30 Apr 2021 11:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lcVO1-0006to-VO for bug-gnu-emacs@gnu.org; Fri, 30 Apr 2021 11:49:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 30 Apr 2021 15:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48117 X-GNU-PR-Package: emacs Original-Received: via spool by 48117-submit@debbugs.gnu.org id=B48117.161979773026504 (code B ref 48117); Fri, 30 Apr 2021 15:49:01 +0000 Original-Received: (at 48117) by debbugs.gnu.org; 30 Apr 2021 15:48:50 +0000 Original-Received: from localhost ([127.0.0.1]:59625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcVNp-0006tO-P5 for submit@debbugs.gnu.org; Fri, 30 Apr 2021 11:48:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lcVNo-0006tD-Kv for 48117@debbugs.gnu.org; Fri, 30 Apr 2021 11:48:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49903) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lcVNj-0000KK-DE for 48117@debbugs.gnu.org; Fri, 30 Apr 2021 11:48:43 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2213 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lcVNh-0000Y0-50; Fri, 30 Apr 2021 11:48:41 -0400 In-Reply-To: <2weeer23xj.fsf@fencepost.gnu.org> (message from Glenn Morris on Fri, 30 Apr 2021 11:22:00 -0400) 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" Xref: news.gmane.io gmane.emacs.bugs:205268 Archived-At: > From: Glenn Morris > Cc: 48117@debbugs.gnu.org > Date: Fri, 30 Apr 2021 11:22:00 -0400 > > This issue has been present forever. Yes, I know. This isn't trivial, or else it would have been solved long ago. > 1) autoload generation is slow. Based on my latest experience, I think this is somewhat exaggerated, especially given that our builds became slower lately. > 2) the dependencies of the loaddefs files are unknown to make, > and are basically "all lisp files". (You can't even say "just those > files with autoload statements", because removing a previously existing > autoload statement changes the output.) > > 3) Traditionally, re-making loaddefs files could make trivial changes > to the output that weren't important (eg ordering of the "no > autoloads" section, timestamping), but would still trigger re-dumping emacs. > Which could then trigger regeneration of the autoloads, and > re-dumping, etc. This may be better nowadays, since there is no > longer timestamp information in the loaddefs files (see autoload-timestamps). What worries me the most is that when 'autoloads' is run (and it is, from time to time), we still end up with outdated loaddefs.el. I think we could live with outdated loaddefs.el for short periods of time, but it looks like running 'autoloads' only updates the part(s) of the file for Lisp files that the build thinks to be responsible for the update. Or something like that, because how else to explain that some parts remain outdated?