From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#46256: [feature/native-comp] AOT eln files ignored if run from build tree Date: Fri, 05 Mar 2021 09:32:35 +0000 Message-ID: References: <86wnutogrh.fsf@gmail.com> <86wnut8fb9.fsf@gmail.com> <861rd1tbpa.fsf@gmail.com> <83pn0km6y3.fsf@gnu.org> <86ft1f8ara.fsf@gmail.com> <83sg5cjdn8.fsf@gnu.org> <83r1kwjcy2.fsf@gnu.org> <83k0qoj9zv.fsf@gnu.org> <83im68j963.fsf@gnu.org> <83tuprhur0.fsf@gnu.org> <831rcu25o2.fsf@gnu.org> <83v9a6zr22.fsf@gnu.org> <83o8fyzjrz.fsf@gnu.org> Reply-To: Andrea Corallo Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12198"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 46256@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Mar 05 10:33:12 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 1lI6pc-00033o-Qs for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Mar 2021 10:33:12 +0100 Original-Received: from localhost ([::1]:48298 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lI6pb-0000he-PX for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 05 Mar 2021 04:33:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36290) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lI6pS-0000gs-HU for bug-gnu-emacs@gnu.org; Fri, 05 Mar 2021 04:33:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49551) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lI6pS-00017f-96 for bug-gnu-emacs@gnu.org; Fri, 05 Mar 2021 04:33:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lI6pS-00010D-5g for bug-gnu-emacs@gnu.org; Fri, 05 Mar 2021 04:33:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Mar 2021 09:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46256 X-GNU-PR-Package: emacs Original-Received: via spool by 46256-submit@debbugs.gnu.org id=B46256.16149367613827 (code B ref 46256); Fri, 05 Mar 2021 09:33:02 +0000 Original-Received: (at 46256) by debbugs.gnu.org; 5 Mar 2021 09:32:41 +0000 Original-Received: from localhost ([127.0.0.1]:32864 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lI6p7-0000ze-62 for submit@debbugs.gnu.org; Fri, 05 Mar 2021 04:32:41 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:60558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lI6p5-0000zS-Uh for 46256@debbugs.gnu.org; Fri, 05 Mar 2021 04:32:40 -0500 Original-Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 1259WZLr026106 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 5 Mar 2021 09:32:36 GMT In-Reply-To: <83o8fyzjrz.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 04 Mar 2021 23:33:20 +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:201510 Archived-At: Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: 46256@debbugs.gnu.org >> Date: Thu, 04 Mar 2021 20:11:27 +0000 >> >> > Now I make some change in Emacs that modifies the ABI hash, and >> > rebuild. The previous subdirectory of native-lisp/ is no longer >> > valid; if I modify some of the preloaded Lisp files, a new .eln file >> > is produced in a new subdirectory of native-lisp/. But now that new >> > subdirectory has only the *.eln files for those Lisp files I modified >> > _after_ the ABI-changing change. Which means most of the preloaded >> > files do not have *.eln files in the native-lisp/ subdirectory that >> > corresponds to the latest ABI. Does this mean Emacs now falls back to >> > using *.elc files when it produces the emacs.pdmp file? >> >> Yes, I think so. ATM if the ABI hash is modified something like 'make >> bootstrap' is needed to re-build all .eln. > > Ouch! We should fix that, because making ABI-breaking changes in the > tree is a frequent case during development, and bootstrap removes all > the previous binaries, which is why I never bootstrap. > > So currently the only way to fill up a newly created subdirectory of > native-lisp/ is to manually delete the *.elc files of all the files in > lisp.mk's $shortlisp list, is that sufficient? Yes I think so. The trouble of using make for building such a system is that make is not aware of the .eln filename, so it should be necessary to ask the Emacs binary about that to create dynamically the precise (multiple target) rule. Not very practical IMO... In the past I've experimented with making the elc .FORCE targets and have the Emacs decide what to do, but the downside there is that for each file that might need compilation Emacs has to start and often decide that nothing has to be done because the .eln is already there... As a consequence a make invocation that was supposed to do nothing became considerably slower. Another option would be to invoke Emacs only once passing to it the list of the .el files to be compiled and the parallelism requested and have Emacs do the job. I think this might be easier and we have in the codebase already the all that's needed for that. The downside is that we'd drift away from how the vanilla build is working. Regards Andrea