From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Third 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 19:25:14 +0100 Message-ID: References: <83y2be6zj8.fsf@gnu.org> <83bl897kag.fsf@gnu.org> <8335tk7h32.fsf@gnu.org> <835yyg5k4p.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22722"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 16 20:26:10 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 1ltaEr-0005o1-QG for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 16 Jun 2021 20:26:09 +0200 Original-Received: from localhost ([::1]:40166 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ltaEq-0000UE-GQ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 16 Jun 2021 14:26:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38630) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ltaEk-0000Tr-3a for bug-gnu-emacs@gnu.org; Wed, 16 Jun 2021 14:26:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41771) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ltaEj-0000sb-Sn for bug-gnu-emacs@gnu.org; Wed, 16 Jun 2021 14:26:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ltaEj-0006z4-Lg for bug-gnu-emacs@gnu.org; Wed, 16 Jun 2021 14:26:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Third Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 16 Jun 2021 18:26:01 +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.162386792426801 (code B ref 48994); Wed, 16 Jun 2021 18:26:01 +0000 Original-Received: (at 48994) by debbugs.gnu.org; 16 Jun 2021 18:25:24 +0000 Original-Received: from localhost ([127.0.0.1]:53317 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ltaE7-0006yD-JU for submit@debbugs.gnu.org; Wed, 16 Jun 2021 14:25:23 -0400 Original-Received: from [217.169.17.33] (port=51795 helo=breton.holly.idiocy.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ltaE5-0006xx-KL for 48994@debbugs.gnu.org; Wed, 16 Jun 2021 14:25:22 -0400 Original-Received: by breton.holly.idiocy.org (Postfix, from userid 501) id 6028A202C9396E; Wed, 16 Jun 2021 19:25:14 +0100 (BST) Mail-Followup-To: Alan Third , Eli Zaretskii , 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@sdf.org Content-Disposition: inline In-Reply-To: <835yyg5k4p.fsf@gnu.org> 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:208644 Archived-At: On Mon, Jun 14, 2021 at 10:19:50PM +0300, Eli Zaretskii wrote: > > I have to admit that I don't really understand this and have a very > > limited understanding of how the makefiles build the .app or not. > > 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. 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. 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. > > > . the Emacs binary > > > > Emacs.app/Contents/MacOS/Emacs > > > > (This is different on GNUstep builds. I think it's > > Emacs.app/Contents/Emacs.) > > > > > . the .pdmp file > > > > The same location as the binary. That was my change and it was done > > that way because I don't really understand any of this but that > > happened to work. > > 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. > > > . the auxiliary executables (hexl, movemail) > > > > I believe they're in Emacs.app/Contents/MacOS/libexec. > > > > (Again, this is different on GNUstep.) > > > > > . the *.eln files > > > > Emacs.app/Contents/Resources/native-elisp, or something. I'm not at a > > Mac to check right now, but definitely under Resources. > > OK, please tell after you find out. Yes, in Emacs.app/Contents/Resources/native-elisp, however that's easy to change as well. > > > Also, I understand that the "normal" Unix-style install has the usual > > > tree hierarchy rooted at /usr or /usr/local, and there everything > > > "just works"? > > You didn't answer this one. Are we using the Unix-style hierarchy in > this case, i.e.: > > . 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. 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. > > > If so, when (at configure time, at installation time, > > > at some other time?) is the decision made whether the install will be > > > one or the other? > > > > 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. I think I can probably fix this now, hopefully without breaking anything... ;) But any observations/recommendations will be gratefully received. -- Alan Third