From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified Date: Wed, 17 Aug 2022 15:50:35 +0200 Message-ID: References: <83k07endtb.fsf@gnu.org> <87zgg9o5nx.fsf@gnus.org> <8335e1o4yg.fsf@gnu.org> <878rnsl683.fsf@gnus.org> <87a685akh8.fsf@gnus.org> <838rnpiur4.fsf@gnu.org> <877d37kva7.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="4232"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) Cc: Eli Zaretskii , Andrea Corallo , 57152@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Aug 17 15:51:22 2022 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 1oOJS5-0000tY-CZ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Aug 2022 15:51:21 +0200 Original-Received: from localhost ([::1]:60162 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oOJS4-0004zC-8c for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 17 Aug 2022 09:51:20 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44712) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOJRp-0004ul-TB for bug-gnu-emacs@gnu.org; Wed, 17 Aug 2022 09:51:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60198) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oOJRm-0000n2-0W for bug-gnu-emacs@gnu.org; Wed, 17 Aug 2022 09:51:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oOJRl-0002UM-Sc for bug-gnu-emacs@gnu.org; Wed, 17 Aug 2022 09:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Aug 2022 13:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57152 X-GNU-PR-Package: emacs Original-Received: via spool by 57152-submit@debbugs.gnu.org id=B57152.16607442479532 (code B ref 57152); Wed, 17 Aug 2022 13:51:01 +0000 Original-Received: (at 57152) by debbugs.gnu.org; 17 Aug 2022 13:50:47 +0000 Original-Received: from localhost ([127.0.0.1]:49944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOJRX-0002Tg-2g for submit@debbugs.gnu.org; Wed, 17 Aug 2022 09:50:47 -0400 Original-Received: from mail-ej1-f44.google.com ([209.85.218.44]:46038) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOJRT-0002TR-S1 for 57152@debbugs.gnu.org; Wed, 17 Aug 2022 09:50:46 -0400 Original-Received: by mail-ej1-f44.google.com with SMTP id dc19so24620534ejb.12 for <57152@debbugs.gnu.org>; Wed, 17 Aug 2022 06:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc; bh=Sy8CtHbMzfqZyopB11eze9OL6UDCbc4U3niVXUXXqe4=; b=IuqfRb2m+JpQRrgPltRVO0PKXcLz2y6qFnwR2VdOUAFDHD0TFkqQflQmgR2KBKEBJw 42Zd63uOMXCKTTQytV959jj735QMuBOX7YFxAKm5WVcVY3Rj2CVTIPmi650qLSYKEFP1 ZV/1C+P5hvRUxVjNGeT/fEmpJuEhBQqjRir5c3rtAJo0NB71azwjBfiKCO7qwE8iNXJ9 YfrRJEK/Dfbf2RmEH6v6MqnXBQa/PFn8fCbhZObUxJQyi9lr0gkcx5hV2bWu3UXvirSF S27OXM58UcdKmYOYuTfsUdiIgi9OMmpVIhv0cwBaGCILDuM19ZjCeGMtg2ZzY68XpWy0 Oxpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc; bh=Sy8CtHbMzfqZyopB11eze9OL6UDCbc4U3niVXUXXqe4=; b=eSqQQ3NE45hXYSb5oYjlMsQVDg4EbE6DD4cnR0ZT08NEN0oMupewi+5OJHzIke5OJQ 2n0+5JNIigppYa1j/U3Nw23CfgrdWy23jtNWAAgj+BHHkiJxIV50OeVVut3rsY8UMqUm BXFBqp/pyhPuO13A8o9tgaKhEKHPxL14WZSLXsENpOxke4kYLcHVma0lHxYqIxWv+Oaw b3nJekMxRBDgzWksh1JW5m/sczn7DXa4NtrHupPkwkRRdS+CAupmMfZlgsh7SFnfC/n5 Njp4NtXmY6ak3hb4gG+dB4gQYu+ke0uV4x84FWyr3dj3spPreb3HoGfSknjlGHrolC6E gZRw== X-Gm-Message-State: ACgBeo2rnIJOLdj1y6em4M7d1CuF2+wP1jPYd//yYs+M+PmMYnsy3jLe XYhIiwFQOjybRyDNPk6iTzg= X-Google-Smtp-Source: AA6agR7ooXT1wxvvp23ukEcT93TDuGP1LOMuV34WSanKRL7CRDppFnuNfaygZW7MRspTqU+oo78Isw== X-Received: by 2002:a17:906:858f:b0:730:87ff:b96 with SMTP id v15-20020a170906858f00b0073087ff0b96mr16580670ejx.649.1660744237907; Wed, 17 Aug 2022 06:50:37 -0700 (PDT) Original-Received: from Mini.fritz.box (pd9e36bc7.dip0.t-ipconnect.de. [217.227.107.199]) by smtp.gmail.com with ESMTPSA id w10-20020a170906130a00b0072ecef772a7sm6830676ejb.160.2022.08.17.06.50.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Aug 2022 06:50:37 -0700 (PDT) In-Reply-To: <877d37kva7.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 17 Aug 2022 12:40:32 +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" Xref: news.gmane.io gmane.emacs.bugs:240078 Archived-At: Lars Ingebrigtsen writes: > Gerd M=C3=B6llmann writes: > >> Could it be that src/Makefile is simply not invoked after lisp/Makefile >> has built loaddefs.*? In Makefile.in we have >> >> SUBDIR =3D $(NTDIR) lib lib-src src lisp >> ... >> all: ${SUBDIR} info $(gsettings_SCHEMAS:.xml=3D.valid) >> >> That is src comes before lisp. Haching something like a second 'make >> -C' at the end seems to do something not entirely unreasonable. > > Hm, interesting... but I think we might end up in a situation where we > first build the Emacs executable, then update the loaddefs.el, and then > build the Emacs executable again. I haven't observed that with your 'echo ...>>foo.el; make' example. But wouldn't that be a hint that there is something fishy in src/Makefile? Or incomplete, or something? > > But perhaps that's OK -- while we're scanning for new loaddefs every > build, there's seldom any new ;;;###autoloads, so the loaddefs.el file > doesn't update all that often. > > I'm not quite sure where the second "make -C" would go, though. I did it this way: diff --git a/Makefile.in b/Makefile.in index bf0f52b514..78103f897f 100644 --- a/Makefile.in +++ b/Makefile.in @@ -358,10 +358,17 @@ ELN_DESTDIR =3D =20 gsettings_SCHEMAS =3D etc/org.gnu.emacs.defaults.gschema.xml =20 -all: ${SUBDIR} info $(gsettings_SCHEMAS:.xml=3D.valid) +all: ${SUBDIR} info $(gsettings_SCHEMAS:.xml=3D.valid) src-depending-on-li= sp =20 .PHONY: all ${SUBDIR} blessmail epaths-force epaths-force-w32 epaths-force= -ns-self-contained etc-emacsver =20 +# Changes in lisp may require us to reconsider the build in src. For +# example, if loaddefs.{el,elc} were built in lisp, we need a new +# .pdmp containing the new autoloads. +.PHONY: src-depending-on-lisp +src-depending-on-lisp: lisp + ${MAKE} -C src + # If configure were to just generate emacsver.tex from emacsver.tex.in # in the normal way, the timestamp of emacsver.tex would always be # newer than that of the pdf files, which are prebuilt in release tarfiles. The dependency on lisp in src-depending-on-lisp is necessary to make sure it runs after lisp has been built. Maybe there is a clever trick to express "only if loaddefs has been regenerated" in some way, but 'make -C src' is quite fast already if it hasn't to do anything, at least compared to other things. There is one pretty strange thing though, which I can't explain. I once got an error "trying to load incoherent eln" which is mentioned in bug#45103. I can't say much else about this though, not even what the cause of this might be. It was a build with -j8 if that matters. Maybe elns are modified during dumping, so that a second dump cannot be done? But that wouldn't explain why it succeeds most of the time. No idea, and not easily reproducible, alas. CC'ing Andrea.