From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: Source file '.../killer-source.el' newer than byte-compiled file Date: Wed, 24 Apr 2019 00:59:15 +0200 Message-ID: <86v9z4fhvg.fsf@zoho.eu> References: <8636m8ipt5.fsf@zoho.eu> <8336m84no5.fsf@gnu.org> <86lg00h8s2.fsf@zoho.eu> <831s1s4kab.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="16099"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Apr 24 01:00:56 2019 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hJ4PH-00040s-R5 for geh-help-gnu-emacs@m.gmane.org; Wed, 24 Apr 2019 01:00:55 +0200 Original-Received: from localhost ([127.0.0.1]:60725 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJ4PG-0003A9-Rs for geh-help-gnu-emacs@m.gmane.org; Tue, 23 Apr 2019 19:00:54 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:59927) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hJ4P3-00037I-FZ for help-gnu-emacs@gnu.org; Tue, 23 Apr 2019 19:00:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hJ4Nn-0004Ya-Ma for help-gnu-emacs@gnu.org; Tue, 23 Apr 2019 18:59:24 -0400 Original-Received: from [195.159.176.226] (port=41064 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hJ4Nn-0004Vy-Ev for help-gnu-emacs@gnu.org; Tue, 23 Apr 2019 18:59:23 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hJ4Nl-0002Hn-3X for help-gnu-emacs@gnu.org; Wed, 24 Apr 2019 00:59:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: help-gnu-emacs@gnu.org Mail-Copies-To: never Cancel-Lock: sha1:oQIC/xqT5Ev92tYU7a7ruZzd7Uk= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:120044 Archived-At: Eli Zaretskii wrote: > Just ignore those messages, really. They are > mostly harmless. You could compile the > dependent file again if you want, but that is > rarely needed, mainly when they define macros > that were changed, and those macros are used > by the files which require a.el. I think you are right, because if you weren't, this should have broken my system one zillion times by now, and that hasn't happened, but I don't understand why. Because think of this scenario: First, a.el is the file that `require' b, so b is `provide'd in b.el. Both a.el and b.el are edited, a.el w/o bugs, b.el *with* bugs. a.el is compiled before b.el is compiled. When a.el is compiled, it requires b, so, depending on the variable `load-prefer-newer' it either gets the buggy b.el _or_ the old b.elc. Because I never touched the variable, which defaults to `nil', a.el will get the old b.elc. Now, because b.elc exists, it doesn't come with bugs, as I would have seen that when I compiled it last time. So a gets a bug-free, but old, version of b. Now the compiler comes to b.el and tells me there is a bug in the file. I fix that bug and it compiles into a new, bug-free b.elc. However a.elc is newer than a.el, so a.el won't recompile to get the new version! So c.el compiles, and it also requires b. Now there is no warning from the byte-compiler since b.elc is newer than b.el. _But_ c got another version of b.elc than did a! What does this situation mean? -- underground experts united http://user.it.uu.se/~embe8573