From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Richard M. Stallman" Newsgroups: gmane.emacs.devel Subject: Re: ldefs-boot.el Date: Sat, 13 Aug 2005 10:40:23 -0400 Message-ID: References: <200508121949.j7CJnKG07646@raven.dms.auburn.edu> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1123945120 16986 80.91.229.2 (13 Aug 2005 14:58:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 13 Aug 2005 14:58:40 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 13 16:58:39 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1E3xS8-0002A0-1w for ged-emacs-devel@m.gmane.org; Sat, 13 Aug 2005 16:57:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1E3xVO-0002P3-QC for ged-emacs-devel@m.gmane.org; Sat, 13 Aug 2005 11:01:02 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1E3xSD-0001Jz-CW for emacs-devel@gnu.org; Sat, 13 Aug 2005 10:57:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1E3xRy-0001Ev-U2 for emacs-devel@gnu.org; Sat, 13 Aug 2005 10:57:30 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1E3xRy-00017D-9O for emacs-devel@gnu.org; Sat, 13 Aug 2005 10:57:30 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1E3xSe-0003Ni-Hx for emacs-devel@gnu.org; Sat, 13 Aug 2005 10:58:12 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1E3xBP-0003eN-Fh; Sat, 13 Aug 2005 10:40:23 -0400 Original-To: Luc Teirlinck In-reply-to: <200508121949.j7CJnKG07646@raven.dms.auburn.edu> (message from Luc Teirlinck on Fri, 12 Aug 2005 14:49:20 -0500 (CDT)) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:42000 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:42000 I recently had to update ldefs-boot.el because a new autoload cookie for a variable had been added. The autoload made its way into loaddefs.el but not into ldefs-boot.el. That is normal. The strange thing was that when the autoload was needed and bootstrapping failed because it was not available, loaddefs.el had already been regenerated and the variable was already defined in it. But apparently only ldefs-boot.el and not the updated loaddefs.el had been loaded at that stage. I don't see a reason not to change that, but there might be a good reason that I don't see yet. Is the moral of this story that each time that somebody adds a new autoload that is necessary for compilation during bootstrapping (as opposed to just an autoload that allows the user to call an interactive function without having to load the file first), one has to update ldefs-boot by overwriting it with a valid up to date copy of loaddefs.el? It seems to be so, with the current design. Of course, most autoloads are not necessary for compilation during bootrapping. As for detecting those that are, the current system, which is to see that bootstrap fails and update ldefs-boot.el, might be the most efficient one.