From unknown Mon Aug 18 06:57:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Aug 2022 07:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 57152 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 57152@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.16602878412949 (code B ref -1); Fri, 12 Aug 2022 07:04:02 +0000 Received: (at submit) by debbugs.gnu.org; 12 Aug 2022 07:04:01 +0000 Received: from localhost ([127.0.0.1]:55523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMOi8-0000lU-S5 for submit@debbugs.gnu.org; Fri, 12 Aug 2022 03:04:01 -0400 Received: from lists.gnu.org ([209.51.188.17]:52688) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMOi4-0000lI-Bp for submit@debbugs.gnu.org; Fri, 12 Aug 2022 03:03:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43952) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMOhx-00014E-ER for bug-gnu-emacs@gnu.org; Fri, 12 Aug 2022 03:03:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41490) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMOhw-0000Tb-Ua for bug-gnu-emacs@gnu.org; Fri, 12 Aug 2022 03:03:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Subject:To:From:Date:mime-version:in-reply-to: references; bh=TPHAz6316riWCvMdtb62CCly3NwdShgKMkKe3F81vOc=; b=R8klvNhHbcVbCH x87G0e7YUdhjRKUaM7fyWSJnyUqaugbJPjJHJkdxnC6lbjrLmIUEAT9fo8/LrjHxuygKsDgjqZQDc d02Xq3BuaFqfg1ahz1Pu47kXgK5kxl+fdct1/uYoMMGP8YD15xwLI+RMdBoVXwYotVwDBt/TzCY9v B48ReEmR6ppAo/3g5RNZCa0zd6HMYw5m2p32gK+MPf2shfHMpEe+X1ZOfgFdtq9mU7blO3lL/I/bU kmlTBvnWofM+bdd2M8xlMhW4sOxEyALQxaeXlJo/ZLT6o1Rrruc8edeo8sa2yHyGFhiiOqypQ6sUQ 8+j9u501vv+Eo+wmSVjQ==; Received: from [87.69.77.57] (port=4784 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 1oMOhw-000332-Df for bug-gnu-emacs@gnu.org; Fri, 12 Aug 2022 03:03:48 -0400 Date: Fri, 12 Aug 2022 10:03:44 +0300 Message-Id: <83k07endtb.fsf@gnu.org> From: Eli Zaretskii X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) The current Makefile's still exhibit the problem that when loaddefs.el is updated, the Emacs executable is not re-dumped to reflect those updates. This leads to an annoying and error-prone practice that one needs to watch the build, detect the telltale "ELC loaddefs.elc" command (which means loaddefs.el was actually modified), and then manually invoke "make" again to re-dump Emacs. AFAICT, the root cause of this is that src/Makefile.in doesn't know about the dependencies of loaddefs.el, which are spelled out in lisp/Makefile.in, and therefore it doesn't realize that loaddefs.el will be modified as part of the current build. In GNU Emacs 29.0.50 (build 1694, i686-pc-mingw32) of 2022-08-12 built on HOME-C4E4A596F7 Repository revision: 687fcc2c40d693bbe342d938e37a4c9a245a1b02 Repository branch: master Windowing system distributor 'Microsoft Corp.', version 5.1.2600 System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600) Configured using: 'configure -C --prefix=/d/usr --with-wide-int --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3'' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP XPM ZLIB Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty make-network-process emacs) Memory information: ((conses 16 42199 12256) (symbols 48 6234 0) (strings 16 16487 2980) (string-bytes 1 396347) (vectors 16 9214) (vector-slots 8 144024 12454) (floats 8 23 45) (intervals 40 268 96) (buffers 888 10)) From unknown Mon Aug 18 06:57:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Aug 2022 15:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57152 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 57152@debbugs.gnu.org Received: via spool by 57152-submit@debbugs.gnu.org id=B57152.166031727822661 (code B ref 57152); Fri, 12 Aug 2022 15:15:02 +0000 Received: (at 57152) by debbugs.gnu.org; 12 Aug 2022 15:14:38 +0000 Received: from localhost ([127.0.0.1]:58600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMWMw-0005tR-Aj for submit@debbugs.gnu.org; Fri, 12 Aug 2022 11:14:38 -0400 Received: from quimby.gnus.org ([95.216.78.240]:55682) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMWMu-0005tA-2G for 57152@debbugs.gnu.org; Fri, 12 Aug 2022 11:14:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=4gF+ZdMKhV/TRmo+aW9os93Fq3EIGBkNIdLum26AAHE=; b=HCI5H9G0ehMfsKI1gUSupAum0P RtXfrRmPnQckK8B4fREmEWEvdCtN+jiorD5df4tp1bmiRD9EF+s5E1RYC16HltjizXwE+oPBCahJg 79ERSdVCDOEdPEr932SltwDX2/j4Bpu9A+xQ8XV9tgTysrgmT/5wuXsNmWGPr971vTN0=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oMWMl-0006Mk-Ee; Fri, 12 Aug 2022 17:14:29 +0200 From: Lars Ingebrigtsen In-Reply-To: <83k07endtb.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 12 Aug 2022 10:03:44 +0300") References: <83k07endtb.fsf@gnu.org> X-Now-Playing: Joni Mitchell's _Joni Mitchell_: "Song To A Seagull" Date: Fri, 12 Aug 2022 17:14:26 +0200 Message-ID: <87zgg9o5nx.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > The current Makefile's still exhibit the problem that when loaddefs.el > is updated, the Emacs executable is not re-dumped to reflect those > updates. This leads to an annoying and error-prone pract [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > The current Makefile's still exhibit the problem that when loaddefs.el > is updated, the Emacs executable is not re-dumped to reflect those > updates. This leads to an annoying and error-prone practice that one > needs to watch the build, detect the telltale "ELC loaddefs.elc" > command (which means loaddefs.el was actually modified), and then > manually invoke "make" again to re-dump Emacs. > > AFAICT, the root cause of this is that src/Makefile.in doesn't know > about the dependencies of loaddefs.el, which are spelled out in > lisp/Makefile.in, and therefore it doesn't realize that loaddefs.el > will be modified as part of the current build. Yes. So the next time you say "make", it'll rebuild the executable. In one way, this is slightly better than what we had before, where loaddefs.el wouldn't be rebuilt until after VCWITNESS had changed, while it's now actually updated all the time (that something changes). It's more... regular? But on the other hand, these updates are seldom actually necessary, so we're doing it a bit too much now, perhaps. Anyway, back to the problem -- I've poked at this quite a bit, but no solutions seem really... nice? If we updated the loaddefs.el file a bit earlier (before we build the Emacs executable), that'd fix the problem, but I could find a way to do that without breaking something else. There's probably something trivial I'm overlooking here. From unknown Mon Aug 18 06:57:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 12 Aug 2022 15:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57152 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: 57152@debbugs.gnu.org Received: via spool by 57152-submit@debbugs.gnu.org id=B57152.166031819932585 (code B ref 57152); Fri, 12 Aug 2022 15:30:02 +0000 Received: (at 57152) by debbugs.gnu.org; 12 Aug 2022 15:29:59 +0000 Received: from localhost ([127.0.0.1]:58644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMWbn-0008TV-4r for submit@debbugs.gnu.org; Fri, 12 Aug 2022 11:29:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40420) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMWbk-0008TG-4H for 57152@debbugs.gnu.org; Fri, 12 Aug 2022 11:29:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47976) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMWbd-0007Ua-3d; Fri, 12 Aug 2022 11:29:49 -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=chCPqoP4I90e4wEHNBDgQjKzKQegGWseryoYeoJWvPM=; b=DUIJKJ7uLCbT tOQrwp5ufnr47cPqHymAcMUr43C65U74bfuxv06GDBq3TAUOlp/NX6k93+eCffjnI3J7uJu55LwK9 gbcY25vK97UsFoDtXl1GdiRF6l4GTOLs4L56bodF7q3dkYSDiE75voojVmtkuga0AxCi0gbfKWlxw ahizEAsHWLgZeKW6jLCJtf2xBMMSZ1Z4xhnftiBeBsL/A41HY+DbE/ug48Co5GJN6M2tDUg6156BC jh7pMqUmPiNcDpEfsV1KxRswQn6WyGH9BbTJYhCk8sD3LJDizleMVuEqpmfIIbWcQpaINQ7JgM/vH h4wEBtnhpXwl1kgA/Y6vKg==; Received: from [87.69.77.57] (port=3994 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 1oMWbb-0004nC-7J; Fri, 12 Aug 2022 11:29:48 -0400 Date: Fri, 12 Aug 2022 18:29:43 +0300 Message-Id: <8335e1o4yg.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87zgg9o5nx.fsf@gnus.org> (message from Lars Ingebrigtsen on Fri, 12 Aug 2022 17:14:26 +0200) References: <83k07endtb.fsf@gnu.org> <87zgg9o5nx.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 57152@debbugs.gnu.org > Date: Fri, 12 Aug 2022 17:14:26 +0200 > > Anyway, back to the problem -- I've poked at this quite a bit, but no > solutions seem really... nice? If we updated the loaddefs.el file a > bit earlier (before we build the Emacs executable), that'd fix the > problem, but I could find a way to do that without breaking something > else. There's probably something trivial I'm overlooking here. Something similar to what we do with $(shortlisp), perhaps? From unknown Mon Aug 18 06:57:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 13 Aug 2022 11:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57152 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 57152@debbugs.gnu.org Received: via spool by 57152-submit@debbugs.gnu.org id=B57152.166039098530680 (code B ref 57152); Sat, 13 Aug 2022 11:44:02 +0000 Received: (at 57152) by debbugs.gnu.org; 13 Aug 2022 11:43:05 +0000 Received: from localhost ([127.0.0.1]:59827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMpXl-0007ym-8q for submit@debbugs.gnu.org; Sat, 13 Aug 2022 07:43:05 -0400 Received: from quimby.gnus.org ([95.216.78.240]:35842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oMpXh-0007yF-Tx for 57152@debbugs.gnu.org; Sat, 13 Aug 2022 07:43:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=UhWkXrbG+8dqaL9dAVJm0poCK6QnnomthRrz1yAc650=; b=G89Dpe2hARrGUh68tDzXOs8j3g mt/Md1APsgWSPlTZ8x4jz13xcHXBlanzuAoYBHU5USV1e8Po0CIGdEzGWeK27LbMFxp8w5vZse/UI 9QTonG0JhHdL2HMuj5OmwIfAJUHQpLvjITT29lT8pK4Pu3bhqRU5pO8sKw9bQOgvOwAc=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oMpXZ-0007CN-2c; Sat, 13 Aug 2022 13:42:55 +0200 From: Lars Ingebrigtsen In-Reply-To: <8335e1o4yg.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 12 Aug 2022 18:29:43 +0300") References: <83k07endtb.fsf@gnu.org> <87zgg9o5nx.fsf@gnus.org> <8335e1o4yg.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAgMAAAAqbBEUAAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAADFBMVEWtpqODfoFLQ0b/ //+EeeQSAAAAAWJLR0QDEQxM8gAAAAd0SU1FB+YIDQslLBitksYAAAEzSURBVCjPhdGxboMwEAbg 3yhk6JQhGZqpj2KGZIYII4U5lQpPkUdIqtKhUysVhP+n7PkMKFtvMPq482EfAHau71yIVwDmcLor HLDJ0iyfkLo8tVJabksXHucAzbgAu5vLXAmTLnB2ZWZUR7uNm2BcfbcvRa84OP6iYhO71Rxx5FdE y9GQjCB9Qg0n5RyTUdoDa9Tkm/HsyoDW82KaV/nqVUC/Me0NKDKFNYPAKnhNeLsUaaYNYHjLcyOo 3seAZ6mTzPUbCfMVVoKzzfHkc8TMDx7ggf0CbrH2lxkN0jHcWkGbNvJ+OnXftOE2pUKir8IKXWUm UkWZhWakt5kz/FCsI2hD2TQZ2bUnimpOLd0kBgEf4j/4uGuCtvmcyrpw7mqCpk5hovpv5LDF3K2r OSyQuiH7Ay0C6D/xevVtAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIyLTA4LTEzVDExOjM3OjQ0KzAw OjAwzqGiJAAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wOC0xM1QxMTozNzo0NCswMDowML/8GpgA AAAASUVORK5CYII= X-Now-Playing: Joni Mitchell's _Wild Things Run Fast_: "Underneath The Streetlight" Date: Sat, 13 Aug 2022 13:42:52 +0200 Message-ID: <878rnsl683.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Something similar to what we do with $(shortlisp), perhaps? Yes, probably. loaddefs.el is already in $(shortlisp), but the problem is that we may later update loaddefs.el again (while doing the scan). Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > Something similar to what we do with $(shortlisp), perhaps? Yes, probably. loaddefs.el is already in $(shortlisp), but the problem is that we may later update loaddefs.el again (while doing the scan). Hm; there must be some easy way to sort of these dependencies. Unfortunately I don't have much time this weekend, but I'll poke away at it again next week. From unknown Mon Aug 18 06:57:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Aug 2022 10:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57152 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 57152@debbugs.gnu.org Received: via spool by 57152-submit@debbugs.gnu.org id=B57152.166055804731864 (code B ref 57152); Mon, 15 Aug 2022 10:08:02 +0000 Received: (at 57152) by debbugs.gnu.org; 15 Aug 2022 10:07:27 +0000 Received: from localhost ([127.0.0.1]:40923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNX0J-0008Hr-22 for submit@debbugs.gnu.org; Mon, 15 Aug 2022 06:07:27 -0400 Received: from quimby.gnus.org ([95.216.78.240]:57726) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNX0H-0008HZ-2N for 57152@debbugs.gnu.org; Mon, 15 Aug 2022 06:07:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Bcdpe/wemLiAFVW+hbCESc5FR+kBqzLhkZ25jQkkt8o=; b=udhCPb2cc61guphhUUeb4qaebE cFGRpZ6YwKA6cuYgUv8zReKF8lcX6hsFAcGvSUJjsO74aK9uaZTMYmHwJe5FErj8/06Jo33McWqQ5 B2GnzNNxmPCTLBP1GSZumnfI9nULBr4I6XIDumKL3oYaCripSiPfyjX6HNOfdysWQI2I=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oNX07-0006CC-VO; Mon, 15 Aug 2022 12:07:18 +0200 From: Lars Ingebrigtsen In-Reply-To: <878rnsl683.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sat, 13 Aug 2022 13:42:52 +0200") References: <83k07endtb.fsf@gnu.org> <87zgg9o5nx.fsf@gnus.org> <8335e1o4yg.fsf@gnu.org> <878rnsl683.fsf@gnus.org> X-Now-Playing: Deutsch Amerikanische Freundschaft's _Gold und Liebe_: "Absolute =?UTF-8?Q?K=C3=B6rperkontrolle?=" Date: Mon, 15 Aug 2022 12:07:15 +0200 Message-ID: <87a685akh8.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: I've spent an hour poking at this. Here's the recipe to reproduce: echo "; ; ; ###autoload ; ; (+ 1 2)" >> lisp/foo.el make This will update loaddefs.el(c), but won't rebuild src/emacs.pdmp. Then, if you say Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) I've spent an hour poking at this. Here's the recipe to reproduce: echo ";;;###autoload ;;(+ 1 2)" >> lisp/foo.el make This will update loaddefs.el(c), but won't rebuild src/emacs.pdmp. Then, if you say make it'll rebuild src/emacs.pdmp. I've tried various things, like making autoloads an order-only prerequisite for $(pdmp) (and various other targets), but the main problem seems to be that Make has already computed the timestamps/dependencies at this point, so even if we're running the update at the "right" time, we don't trigger the $(pdmp) rule. And moving this earlier results in problems with the boot build. I think it'd be helpful if somebody with fresh eyes could take a look at this. From unknown Mon Aug 18 06:57:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Aug 2022 11:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57152 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: 57152@debbugs.gnu.org Received: via spool by 57152-submit@debbugs.gnu.org id=B57152.166056471327779 (code B ref 57152); Mon, 15 Aug 2022 11:59:01 +0000 Received: (at 57152) by debbugs.gnu.org; 15 Aug 2022 11:58:33 +0000 Received: from localhost ([127.0.0.1]:41089 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNYjp-0007Dy-3w for submit@debbugs.gnu.org; Mon, 15 Aug 2022 07:58:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNYjj-0007Dh-Gc for 57152@debbugs.gnu.org; Mon, 15 Aug 2022 07:58:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36988) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oNYje-0003w3-1G; Mon, 15 Aug 2022 07:58:22 -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=IC22e+19NYGOe7v4moK/9G33CnsV6icAMqZsReGgM7s=; b=eVKPFEA1y+C0 q19G7OQBVh+cWUAU1H/u1AQBPmyK1s1Ke7H7n3+iWKTzs5kYv5bp3TRZwtD69UpyJ3KGWafpnsTkD A05P4dc+KGdlsFVb3VuvagrbTHK1Kia9/YjHSveAdBWdT18LOkYFiw0Kehbcz/AQK5JYraYyjCTPY mpTr2A7eMMh21s8I6+IGAk24LYJWJlqLHfBE8o/nJOc585MFIVnhYKtdJ5t3IbO0QPM2kAbDotNe8 JWD8pmB2Gp+YskMn/Ge+QyU8bTVRewj41e28r881et5nOtQ9/vzWywBEbR5SOSoFSkdRUDGfhxXFT vgPfWw3mvjukskT92DSCFQ==; Received: from [87.69.77.57] (port=4694 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 1oNYjd-0002HH-C9; Mon, 15 Aug 2022 07:58:21 -0400 Date: Mon, 15 Aug 2022 14:58:07 +0300 Message-Id: <838rnpiur4.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87a685akh8.fsf@gnus.org> (message from Lars Ingebrigtsen on Mon, 15 Aug 2022 12:07:15 +0200) References: <83k07endtb.fsf@gnu.org> <87zgg9o5nx.fsf@gnus.org> <8335e1o4yg.fsf@gnu.org> <878rnsl683.fsf@gnus.org> <87a685akh8.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 57152@debbugs.gnu.org > Date: Mon, 15 Aug 2022 12:07:15 +0200 > > I've tried various things, like making autoloads an order-only > prerequisite for $(pdmp) (and various other targets), but the main > problem seems to be that Make has already computed the > timestamps/dependencies at this point, so even if we're running the > update at the "right" time, we don't trigger the $(pdmp) rule. That cannot be the reason, AFAIK. Make begins by reading all the rules and dependencies in the Makefile and producing a DAG for rebuilding the targets; then it walks the DAG invoking commands as it goes. Thus, a target that is going to be rebuilt will automatically trigger the rules of all the targets that depend on it, as long as the dependencies are known to Make in full. IOW, Make doesn't update the timestamps of files during the build, it figures it all out in advance. So I think the problem here is that the rules which trigger regeneration of loaddefs.el are in lisp/Makefile, while the rules for building $(pdmp) are in src/Makefile. So maybe moving or duplicating the loaddefs.el rules in src/Makefile will do the trick. From unknown Mon Aug 18 06:57:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Aug 2022 13:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57152 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Lars Ingebrigtsen , 57152@debbugs.gnu.org Received: via spool by 57152-submit@debbugs.gnu.org id=B57152.16605703754854 (code B ref 57152); Mon, 15 Aug 2022 13:33:02 +0000 Received: (at 57152) by debbugs.gnu.org; 15 Aug 2022 13:32:55 +0000 Received: from localhost ([127.0.0.1]:41296 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNaD9-0001GE-0W for submit@debbugs.gnu.org; Mon, 15 Aug 2022 09:32:55 -0400 Received: from mail-ed1-f50.google.com ([209.85.208.50]:44601) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oNaD5-0001Fy-0H for 57152@debbugs.gnu.org; Mon, 15 Aug 2022 09:32:52 -0400 Received: by mail-ed1-f50.google.com with SMTP id t5so9567874edc.11 for <57152@debbugs.gnu.org>; Mon, 15 Aug 2022 06:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc; bh=IDD4gg/JAJzL0HQUIYxO3Vqpp5nmYG81J90rweycf4g=; b=EU+TyljM7siClcd1Bi5V17Mlc7gYMGMJ1gMcQ2K0bSSwnMxnJfRUfdtD62Hng4Foxt Q0rMtef/K9RT43J+54vsDtzAFK4QvXGpLyukeR6+nb5+sU6fC6zUByVBUFsh5CvlWkfo KuW2U82UdD6psW+mGofcxY0e3BwoavLknsiZo4ScUY4LTpus6v/zaNzpVuL1X3gmfLbL rxCxXiJRcS7otpZe/esqjfPvCdvBOiBaJSVAJdePQ1+3T4IklSHcnBbEaPjIugmZjQOM 6I/+JR3JGaI9MA2crnoxdej+IwIqD+pt7NwS7r2gtPitSyKiPveJ255p0JrFn0JnSufU +hXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc; bh=IDD4gg/JAJzL0HQUIYxO3Vqpp5nmYG81J90rweycf4g=; b=5YQ/2R5JV9TmR0qs5lvy4Lxcxqmwhqs+SlHPAMvL00vfYuFqumn5qGpYXVMv8Vg1jh fuSu9l+LFvoUfuAnMG6VkjIC248vbOt8ET8uNhf5CsAiIRsbNGxx9mnc0ojzIc+P9Wja Yb967/j8ieBrAXDZHCFPXgaY3zAD9yqvXo84vK/e94jjRZGpNjOuhseNxzLTDo0kxaT1 CQ8Ifg7EP2kbTOkwiCYOiIoO6x/v9NuS2CMdZtlCmtpx9RWibQ4d2pmwNqZiVJ10ZJW6 tTquzdjoXMF8myX/Q8mfCldCk4c3W88NvH+PaVcHiZW0iywsWrAzJVQlw5uEb5ccJ0kD 7zHg== X-Gm-Message-State: ACgBeo0Gi737skUOVbGUYFPsx+Fim4E5DQq5MKxmfEqAVt8cGFq5Wk/v 8NujQAFDWRy+YxLVqplbKtPeznF6pUk= X-Google-Smtp-Source: AA6agR4isX07iVxmGtDtwzbyaSDhC/PcKDyoe6rMRAMZYUDnAg9F6lnFxEtUrbC35lI9ljlfO5yvgw== X-Received: by 2002:a05:6402:2816:b0:434:ed38:16f3 with SMTP id h22-20020a056402281600b00434ed3816f3mr14629427ede.116.1660570364652; Mon, 15 Aug 2022 06:32:44 -0700 (PDT) Received: from Mini.fritz.box (pd9e36cf6.dip0.t-ipconnect.de. [217.227.108.246]) by smtp.gmail.com with ESMTPSA id o10-20020a50fd8a000000b0043ba1ecb0dfsm6590641edt.75.2022.08.15.06.32.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Aug 2022 06:32:44 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <838rnpiur4.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 15 Aug 2022 14:58:07 +0300") 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> Date: Mon, 15 Aug 2022 15:32:43 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Lars Ingebrigtsen >> Cc: 57152@debbugs.gnu.org >> Date: Mon, 15 Aug 2022 12:07:15 +0200 >> >> I've tried various things, like making autoloads an order-only >> prerequisite for $(pdmp) (and various other targets), but the main >> problem seems to be that Make has already computed the >> timestamps/dependencies at this point, so even if we're running the >> update at the "right" time, we don't trigger the $(pdmp) rule. > > So maybe moving or duplicating the loaddefs.el rules in src/Makefile > will do the trick. Could it be that src/Makefile is simply not invoked after lisp/Makefile has built loaddefs.*? In Makefile.in we have SUBDIR = $(NTDIR) lib lib-src src lisp ... all: ${SUBDIR} info $(gsettings_SCHEMAS:.xml=.valid) That is src comes before lisp. Haching something like a second 'make -C' at the end seems to do something not entirely unreasonable. From unknown Mon Aug 18 06:57:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Aug 2022 10:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57152 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 57152@debbugs.gnu.org Received: via spool by 57152-submit@debbugs.gnu.org id=B57152.166073246529318 (code B ref 57152); Wed, 17 Aug 2022 10:35:02 +0000 Received: (at 57152) by debbugs.gnu.org; 17 Aug 2022 10:34:25 +0000 Received: from localhost ([127.0.0.1]:49493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOGNU-0007co-W8 for submit@debbugs.gnu.org; Wed, 17 Aug 2022 06:34:25 -0400 Received: from quimby.gnus.org ([95.216.78.240]:43972) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOGNT-0007cb-OZ for 57152@debbugs.gnu.org; Wed, 17 Aug 2022 06:34:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=23H3VMntiZjqYGj7r+qFFO6FUdq0jzBJ87dQRovk/0g=; b=lXbgC4Gq3cgyRA2c2ERHnhhOZK qux4QQZ3btFatY/LbmZ/AeCsDh+vhfD/9giNM17LF5Ljmog3Z4O2Bbj6XUbn2c3REzW8yeGt4eQ/g dkpv8eLOxm0fOWhbJFcN0L0jqT9D0iPDZcFODcmXXeBStlDBRlkmoJBCkmmlHylYLuUU=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oOGNK-0007yL-F7; Wed, 17 Aug 2022 12:34:16 +0200 From: Lars Ingebrigtsen In-Reply-To: <838rnpiur4.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 15 Aug 2022 14:58:07 +0300") 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> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAJFBMVEX3vR78xBz8xiPw vCPOoybDojcoU6F+g3CckVpWa4RjcXr///9rP2zAAAAAAWJLR0QLH9fEwAAAAAd0SU1FB+YIEQof H5nZr7kAAAGKSURBVDjLbZM9TgNBDIVnkgtgL0ghnU2TNlmgD1oOgOAKEVyDgoiUKZBouSn2en48 A5Miib/187PHGyLMh+wLUH8iMwcLYwYaJi5A/gjUEPAcFoCYckRFgiksIDLa8yxPuxM0XaUEENcE Dgt5Um2glGVAdFJMxLfTNO0nPY+7AkDAMC7H3RjHm3GZMyQBiFUhlamAwcL6wQaQZc1p4FyJGwVI qoPerojLqGpWBVZB+nHNJwAwPMus+KWCOFcHuHyV4awOTec29eMTwf17nyFjWb3x3Rc2QO9SbG0+ PomclIxK7wjp9LCpSuIKrAe+OiB+O6mt+kdpY3VmOv2pIbbWAo7MvV2C6zPAcedqaHe6KTPY+gyw BerBAtMKGsA83xChAWXAFawNIHlAFZTdpRbU3Q1F6sdcgQeagSI6aKs8L5HUkG3nnGYr1rrKINkS KX1hCkh76WvkDF+c3Fub9zeEiE0NMgPcxYsz72pr1YurmIpf7Ns+QqfDabX6BuuLk5Wayq6Pf0A/ rHQjv8c1hIV9NDCUAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIyLTA4LTE3VDEwOjMxOjMxKzAwOjAw kuVh3wAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wOC0xN1QxMDozMTozMSswMDowMOO42WMAAAAA SUVORK5CYII= X-Now-Playing: King Crimson's _Three of a Perfect Pair_: "Man With an Open Heart" Date: Wed, 17 Aug 2022 12:34:13 +0200 Message-ID: <87bksjkvkq.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> I've tried various things, like making autoloads an order-only >> prerequisite for $(pdmp) (and various other targets), but the main >> problem seems to be that Make has already computed the >> tim [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> I've tried various things, like making autoloads an order-only >> prerequisite for $(pdmp) (and various other targets), but the main >> problem seems to be that Make has already computed the >> timestamps/dependencies at this point, so even if we're running the >> update at the "right" time, we don't trigger the $(pdmp) rule. [...] > IOW, Make doesn't update the timestamps of files during the build, it > figures it all out in advance. I think we're saying the same thing. =F0=9F=98=80 > So I think the problem here is that the rules which trigger > regeneration of loaddefs.el are in lisp/Makefile, while the rules for > building $(pdmp) are in src/Makefile. > > So maybe moving or duplicating the loaddefs.el rules in src/Makefile > will do the trick. There really are no rules for loaddefs.el -- Emacs itself (via loaddefs-gen) figures out whether loaddefs.el needs updating. I.e., Make knows nothing about the dependencies loaddefs.el really has. We could make loaddefs.el depend on all .el files, but then we'd rebuild the Emacs executable every time we change an .el file, and we don't want to do that, either. From unknown Mon Aug 18 06:57:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Aug 2022 10:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57152 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: Eli Zaretskii , 57152@debbugs.gnu.org Received: via spool by 57152-submit@debbugs.gnu.org id=B57152.166073284629891 (code B ref 57152); Wed, 17 Aug 2022 10:41:02 +0000 Received: (at 57152) by debbugs.gnu.org; 17 Aug 2022 10:40:46 +0000 Received: from localhost ([127.0.0.1]:49501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOGTe-0007m3-35 for submit@debbugs.gnu.org; Wed, 17 Aug 2022 06:40:46 -0400 Received: from quimby.gnus.org ([95.216.78.240]:44098) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOGTc-0007lp-2K for 57152@debbugs.gnu.org; Wed, 17 Aug 2022 06:40:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Wu7Cri7LFifmvsNZVV/jYy+/0PrZO5jw1Pd63ehssug=; b=DFIRsHFIFKgveaQvIo1UTeBkLS FQsnxffowt3iMvS+277bRk4/SHfD82OSeqVuLw8aq94wXitHTnSafK8w/biDMQWsE4umq11H6g85y F8v4INPnBMy4BGafMwzglxbuYqUF1tuVu7vhvb4IMIvc+kRtTedYT9tGCmdkmwFvKwsg=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oOGTT-000826-7E; Wed, 17 Aug 2022 12:40:37 +0200 From: Lars Ingebrigtsen In-Reply-To: ("Gerd =?UTF-8?Q?M=C3=B6llmann?="'s message of "Mon, 15 Aug 2022 15:32:43 +0200") 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> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAJFBMVEX3vR78xBz8xiPw vCPOoybDojcoU6F+g3CckVpWa4RjcXr///9rP2zAAAAAAWJLR0QLH9fEwAAAAAd0SU1FB+YIEQof H5nZr7kAAAGKSURBVDjLbZM9TgNBDIVnkgtgL0ghnU2TNlmgD1oOgOAKEVyDgoiUKZBouSn2en48 A5Miib/187PHGyLMh+wLUH8iMwcLYwYaJi5A/gjUEPAcFoCYckRFgiksIDLa8yxPuxM0XaUEENcE Dgt5Um2glGVAdFJMxLfTNO0nPY+7AkDAMC7H3RjHm3GZMyQBiFUhlamAwcL6wQaQZc1p4FyJGwVI qoPerojLqGpWBVZB+nHNJwAwPMus+KWCOFcHuHyV4awOTec29eMTwf17nyFjWb3x3Rc2QO9SbG0+ PomclIxK7wjp9LCpSuIKrAe+OiB+O6mt+kdpY3VmOv2pIbbWAo7MvV2C6zPAcedqaHe6KTPY+gyw BerBAtMKGsA83xChAWXAFawNIHlAFZTdpRbU3Q1F6sdcgQeagSI6aKs8L5HUkG3nnGYr1rrKINkS KX1hCkh76WvkDF+c3Fub9zeEiE0NMgPcxYsz72pr1YurmIpf7Ns+QqfDabX6BuuLk5Wayq6Pf0A/ rHQjv8c1hIV9NDCUAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIyLTA4LTE3VDEwOjMxOjMxKzAwOjAw kuVh3wAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0wOC0xN1QxMDozMTozMSswMDowMOO42WMAAAAA SUVORK5CYII= X-Now-Playing: King Crimson's _Three of a Perfect Pair_: "Nuages (That Which Passes, Passes Like Clouds)" Date: Wed, 17 Aug 2022 12:40:32 +0200 Message-ID: <877d37kva7.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Gerd =?UTF-8?Q?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 = $(NTDIR) lib lib-src src lisp > ... > all: ${SUBDIR} info $(gsetti [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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. 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. From unknown Mon Aug 18 06:57:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Aug 2022 12:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57152 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: 57152@debbugs.gnu.org Received: via spool by 57152-submit@debbugs.gnu.org id=B57152.166073811331369 (code B ref 57152); Wed, 17 Aug 2022 12:09:02 +0000 Received: (at 57152) by debbugs.gnu.org; 17 Aug 2022 12:08:33 +0000 Received: from localhost ([127.0.0.1]:49682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOHqS-00089k-QC for submit@debbugs.gnu.org; Wed, 17 Aug 2022 08:08:33 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58182) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOHqQ-00089W-C3 for 57152@debbugs.gnu.org; Wed, 17 Aug 2022 08:08:23 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38136) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oOHqL-0001W6-1Y; Wed, 17 Aug 2022 08:08:17 -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=BaydbptGa9Zur7+AgHdxqjhczQkr21oD1PjFP8D7Myw=; b=jvekj60vCIOF irPh+VDKvxIUwCcrO1pmOiA+QaCeM+BhG4xlABWh2P/Fu+fQyZygsJpz5F0GCLhXI6BoO3McNpif2 c6u9dOZantAmqDzQi05h0RbEtAZyNKUlhRx4QsZLgEJg8pK75WiWz3HwUlvLQ6Xdv2sVHkJCq8BH/ 3HLYZLAFq/1jU47E9l336TtkXYQ0gM0u8wZNuvqHx8J7uFsZKR7he/GWvpgCwlndWjObOzQF+tWw2 LmDfdNsNpj7UdHdFx1Fl+enRO8UFIsbhMCQeu8yjU7lttxhp5/04YfpbflftktkUrJ05Wgh3b+6+H D/5KG0NgdvQ4QvwV5HcQHQ==; Received: from [87.69.77.57] (port=2052 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 1oOHqK-0008KW-Gj; Wed, 17 Aug 2022 08:08:16 -0400 Date: Wed, 17 Aug 2022 15:08:08 +0300 Message-Id: <831qtfdqdz.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87bksjkvkq.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 17 Aug 2022 12:34:13 +0200) 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> <87bksjkvkq.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: 57152@debbugs.gnu.org > Date: Wed, 17 Aug 2022 12:34:13 +0200 > > We could make loaddefs.el depend on all .el files, but then we'd rebuild > the Emacs executable every time we change an .el file, and we don't want > to do that, either. What about using move-if-change? That's a standard technique of avoiding large rebuilds because some dependency's rules cannot be easily stated. From unknown Mon Aug 18 06:57:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified 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 X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: Eli Zaretskii , Andrea Corallo , 57152@debbugs.gnu.org Received: via spool by 57152-submit@debbugs.gnu.org id=B57152.16607442479532 (code B ref 57152); Wed, 17 Aug 2022 13:51:01 +0000 Received: (at 57152) by debbugs.gnu.org; 17 Aug 2022 13:50:47 +0000 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 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 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) 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) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <877d37kva7.fsf@gnus.org> (Lars Ingebrigtsen's message of "Wed, 17 Aug 2022 12:40:32 +0200") 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> Date: Wed, 17 Aug 2022 15:50:35 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From unknown Mon Aug 18 06:57:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 18 Aug 2022 12:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57152 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: Eli Zaretskii , Andrea Corallo , 57152@debbugs.gnu.org Received: via spool by 57152-submit@debbugs.gnu.org id=B57152.166082683127834 (code B ref 57152); Thu, 18 Aug 2022 12:48:01 +0000 Received: (at 57152) by debbugs.gnu.org; 18 Aug 2022 12:47:11 +0000 Received: from localhost ([127.0.0.1]:54178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOevW-0007Es-Ng for submit@debbugs.gnu.org; Thu, 18 Aug 2022 08:47:10 -0400 Received: from quimby.gnus.org ([95.216.78.240]:56482) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOevV-0007Ee-Gv for 57152@debbugs.gnu.org; Thu, 18 Aug 2022 08:47:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=BUW5YetbcSWSN6OoT3DxRSnl0HOp4DlLSRQVBoDnxEk=; b=NqpwTQB60PpKNVGwdH9peI+n46 UK3gPR18hFayl7lMtsGn/f6OZGwLXM/O69KN1JsP70tYmlhnAahu1nLupkLfA59pgWO91ES1EL53D gPJNPyEWiGVB8nE680uSbu59R2ANn21OIRBcT8Bs3puWRfap+eErX4UVYCHk0wGZ8RvQ=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oOevJ-0007T6-Ok; Thu, 18 Aug 2022 14:46:59 +0200 From: Lars Ingebrigtsen In-Reply-To: ("Gerd =?UTF-8?Q?M=C3=B6llmann?="'s message of "Wed, 17 Aug 2022 15:50:35 +0200") 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> X-Now-Playing: Alwanzatar's _Being for the Benefit of =?UTF-8?Q?Kaf=C3=A9_?= =?UTF-8?Q?H=C3=A6rverk!=5F:?= "Marspass" Date: Thu, 18 Aug 2022 14:46:55 +0200 Message-ID: <87fshthg74.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Gerd =?UTF-8?Q?M=C3=B6llmann?= writes: >> I'm not quite sure where the second "make -C" would go, though. > > I did it this way: [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Gerd M=C3=B6llmann writes: >> I'm not quite sure where the second "make -C" would go, though. > > I did it this way: [...] > +all: ${SUBDIR} info $(gsettings_SCHEMAS:.xml=3D.valid) src-depending-on-= lisp Ah, right. I've now done some testing with your patch, and it fixes the problem (without introducing any new extra src/emacs builds in a bootstrap or otherwise). So I just went ahead and pushed it. :-) > 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. Yes, I've seen those, too, but very seldom (like -- once a month?), and I haven't been able to reproduce it. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 18 08:48:19 2022 Received: (at control) by debbugs.gnu.org; 18 Aug 2022 12:48:19 +0000 Received: from localhost ([127.0.0.1]:54183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOewd-0007JP-3d for submit@debbugs.gnu.org; Thu, 18 Aug 2022 08:48:19 -0400 Received: from quimby.gnus.org ([95.216.78.240]:56500) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOewb-0007Iv-VC for control@debbugs.gnu.org; Thu, 18 Aug 2022 08:48:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=y9bwmWkV11ILKAz4F56MDHPSwtaCT1QTaHBfs9Xrr0k=; b=S9qgueJOH12Q2T9L4hKnKtZ9yM w4o7JX1kS4Nz2uWMssO04mcibj7RudBrs29L3sgHnTIs4H+0vgE462tjupdrPiwnMc93mylj68bZf 2/hOrSX+RpL5X07oksaDfqo7mDyUkVD67swAdWUZsVyv3W63m5D/1RxCj10SNxdEKoL8=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oOewT-0007TZ-Ss for control@debbugs.gnu.org; Thu, 18 Aug 2022 14:48:11 +0200 Date: Thu, 18 Aug 2022 14:48:09 +0200 Message-Id: <87edxdhg52.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #57152 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 57152 29.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 57152 29.1 quit From unknown Mon Aug 18 06:57:59 2025 X-Loop: help-debbugs@gnu.org Subject: bug#57152: 29.0.50; Emacs executable isn't rebuilt when loaddefs.el is modified Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 Aug 2022 09:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57152 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: Eli Zaretskii , Andrea Corallo , 57152@debbugs.gnu.org Received: via spool by 57152-submit@debbugs.gnu.org id=B57152.166090109324429 (code B ref 57152); Fri, 19 Aug 2022 09:25:01 +0000 Received: (at 57152) by debbugs.gnu.org; 19 Aug 2022 09:24:53 +0000 Received: from localhost ([127.0.0.1]:57391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOyFG-0006Lv-G1 for submit@debbugs.gnu.org; Fri, 19 Aug 2022 05:24:52 -0400 Received: from mail-ed1-f51.google.com ([209.85.208.51]:42501) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oOyFB-0006Lf-4F for 57152@debbugs.gnu.org; Fri, 19 Aug 2022 05:24:49 -0400 Received: by mail-ed1-f51.google.com with SMTP id z20so4908288edb.9 for <57152@debbugs.gnu.org>; Fri, 19 Aug 2022 02:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=JGSFJWeLOIr9YjxuFyi+Zngfo0lpesoKikinSU71A9c=; b=OrCb3e6tkhk70qOY6hIAcFQaAmYwpQeXMXmrqfeAptsH6sslH97IFMYZS9aIETDjYK YMKccNTgRRhmApPxpKIkw61ht0KsLG4lT2ML5C4RxarsCzi/CeXxiUFNP5Yng15LOwJ8 7eiwEJpkloqQG6D8319KKDSNVCESV8FoxNUeSHkups4Sa6F45ET+N+rtWYsR6GBmg+SL ytuFQz2hJhmaN97RPDPKZmA/cffNxZhMQaiylj2MBPuolDgBaublwjhZkcpBR3W0lR3c 1Rx9LXop++1d1d60Hs1Tx6ZCN3KqoJDDNFGoqg4ODUvniivs/eA2VBK2So7jAnOAnhNK nxFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=JGSFJWeLOIr9YjxuFyi+Zngfo0lpesoKikinSU71A9c=; b=MZYvUqQX3Ef0rsvfGgxaHL1vEVPAMCUVjDkQjTm/+MwCer9MjbWHyroVFLJTm/w3JJ 8WxO+9hCP+7zvv03DSF5HE8CxQCyMSQenuxlzjkbcA8GmgaFxrRqiS3Ebq6aXvTUd3ID oHtj/XhtC4RYSM0UzYwC8+yKgeV7Vxhu4w7RJHmf+Pgd6S4HkpGdraXD4AOvecaCiKuT F+P+GjAzrxi5FrnhsWHQKI6LpM9f393CgxC/G2Hz+VUGdNdTTStk+FD8+dK2ZI7fqPhq PawCUsKAhbHhua+1EMVQ9e4L6d3NDsePqczXAI5/WgErC7Sk7mVTtzs4EAuuhvrmqS19 pd6g== X-Gm-Message-State: ACgBeo1+dnA1+x9mjirxQYpB6u7v2BIUWQYwxnKYF/rmydQfzVRKCr1x n+wwXzwkLG/+DJsvs0cnu6o= X-Google-Smtp-Source: AA6agR5IFRuTaeCUhOov+98MlB101mMK9bGHTcxWgrvACHs+72gPS7EDKHE+HZk6p5Bq+Em2enGaLw== X-Received: by 2002:a05:6402:2751:b0:443:d90a:43d4 with SMTP id z17-20020a056402275100b00443d90a43d4mr5513940edd.368.1660901079159; Fri, 19 Aug 2022 02:24:39 -0700 (PDT) Received: from [192.168.178.21] (pd9e36a1e.dip0.t-ipconnect.de. [217.227.106.30]) by smtp.gmail.com with ESMTPSA id c14-20020aa7c98e000000b0043bea0a48d0sm2720535edt.22.2022.08.19.02.24.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 19 Aug 2022 02:24:37 -0700 (PDT) Message-ID: <48845bf9-f24b-a2f8-9940-833cbc000354@gmail.com> Date: Fri, 19 Aug 2022 11:24:36 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Content-Language: en-US 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> <87fshthg74.fsf@gnus.org> From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <87fshthg74.fsf@gnus.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 22-08-18 14:46 , Lars Ingebrigtsen wrote: > So I just went ahead and pushed it. :-) Oh no :-). > 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. > Yes, I've seen those, too, but very seldom (like -- once a month?), and > I haven't been able to reproduce it. If anyone reading this has any idea, be it just a gut feeling or something, how to reproduce this failure, even if not 100% reliable, I'd be grateful to hear it.