From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS) Date: Wed, 16 Jun 2021 21:45:50 +0300 Message-ID: <83fsxh1wdd.fsf@gnu.org> References: <83y2be6zj8.fsf@gnu.org> <83bl897kag.fsf@gnu.org> <8335tk7h32.fsf@gnu.org> <835yyg5k4p.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18026"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org To: Alan Third Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 16 20:48:50 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 1ltaao-0004W8-D0 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 16 Jun 2021 20:48:50 +0200 Original-Received: from localhost ([::1]:43904 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ltaan-0006Fd-8e for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 16 Jun 2021 14:48:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44608) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ltaZ4-0003f6-M8 for bug-gnu-emacs@gnu.org; Wed, 16 Jun 2021 14:47:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41797) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ltaZ4-00074O-D7 for bug-gnu-emacs@gnu.org; Wed, 16 Jun 2021 14:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ltaZ4-0000jr-Bf for bug-gnu-emacs@gnu.org; Wed, 16 Jun 2021 14:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Jun 2021 18:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48994 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 48994-submit@debbugs.gnu.org id=B48994.162386916732573 (code B ref 48994); Wed, 16 Jun 2021 18:47:02 +0000 Original-Received: (at 48994) by debbugs.gnu.org; 16 Jun 2021 18:46:07 +0000 Original-Received: from localhost ([127.0.0.1]:53343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ltaYB-0008So-B4 for submit@debbugs.gnu.org; Wed, 16 Jun 2021 14:46:07 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:46378) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ltaY7-0008Kp-Pk for 48994@debbugs.gnu.org; Wed, 16 Jun 2021 14:46:05 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:56636) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ltaY1-0006Ec-6g; Wed, 16 Jun 2021 14:45:57 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1031 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 1ltaXv-0000mw-MB; Wed, 16 Jun 2021 14:45:57 -0400 In-Reply-To: (message from Alan Third on Wed, 16 Jun 2021 19:25:14 +0100) 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:208645 Archived-At: > Date: Wed, 16 Jun 2021 19:25:14 +0100 > From: Alan Third > Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org > > > My primary worry is not the Makefiles, it's what the installed Emacs > > does upon startup to find its requisite files. > > I've done a lot of digging about and it looks like a bit of a mess, > frankly. It could be. But let me first ask you: did you understand how Emacs finds the directory with the *.eln files, and how that is related to finding the .pdmp file? These two parts are looked for together, and the place where we find the .pdmp file tells us directly where to look for the *.eln files. If this is "messy" on macOS, in either of the two types of install, then we should fix that first. >From what you describe, it sounds like not everything is well in that department: > configure hard-codes "lispdirrel" to Contents/Resources/lisp, which is > obviously wrong on a Unix style install, but is only "correct" on a > bundled app install because argv0 is set to the root of the app bundle > instead of the actual executable. > > I don't know why argv0 is set that way, but it must be how NS apps > work because I haven't yet seen any code changing it yet. > > The other place that's causing trouble is this wee bit in emacs.c: > > /* Assume the Emacs binary lives in a sibling directory as set up by > the default installation configuration. */ > const char *go_up = "../../../../bin/"; > > Which I assume works correctly in a Unix style install but doesn't > work in an app bundle install. So we need to make NS-specific changes that will make this work correctly both in Unix-style and the app bundle style install. Do you understand how to fix this part? I'll gladly help you if needed. > I'm feeling that perhaps we should expose the ns_self_contained > variable from configure/makefile to the C code so we can do different > things in a couple of places depending on what type of install we're > using. Trying to use the same code for both seems rather more > difficult than it needs to be. If the decision on the type of the install is at configure time, then we can have compile-time conditions in the source, yes. > > If the pdumper file is near the binary, I think Emacs will decide it's > > running uninstalled, and will look for the *.eln files in > > ../native-lisp relative to where the binary lives. Which is not > > necessarily what you want, AFAIU. > > That's easy enough to change. If I put it in the libexec directory it > works just as well. Then let's do that. In general, as much similarity between the two cases as is feasible is better, because it will make the code less messy, and will require us to remember fewer special cases. > > . Emacs binary in /usr/bin > > . the .pdmp file in /usr/libexec/emacs/VERSION/ARCHITECTURE > > . the *eln files in /usr/lib/emacs/VERSION/native-lisp > > > > ? > > Sorry, I must've missed it. > > Yes, a normal Unix style install should be like that. OK, then the Unix style install should already be working. Then I wonder how come this very install caused the OP trouble. But we can revisit it later, once the code whch looks for .pdmp and *.eln files is finalized. > However the OP appears to be using a Unix style install with a > different install prefix and is getting app bundle install paths in > his errors, specifically Contents/Resources/lisp, which I mentioned at > the top of the email. I wonder how this could happen, if the Unix style install is supposed to "just work". > > > I believe there's a ./configure flag. But like I said before, for the > > > other paths there's a run-time check, so I'm not sure how it all ties > > > together. > > > > Which run-time check did you have in mind? > > ns_exec_path, and friends. They return the app bundle paths if the > directories exist, and nil otherwise, then the code that calls them > modifies the search paths depending on the result. It's okay to use that, although I'd expect the install location to be known at compile time? > I think I can probably fix this now, hopefully without breaking > anything... ;) Fine, please do, but let's try doing that one step at a time... Thanks.