GNU bug report logs - #48994
28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS)

Previous Next

Package: emacs;

Reported by: Matthew Bauer <mjbauer95 <at> gmail.com>

Date: Sun, 13 Jun 2021 03:14:01 UTC

Severity: normal

Tags: patch

Found in version 28.0.50

Done: Alan Third <alan <at> idiocy.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48994 in the body.
You can then email your comments to 48994 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Sun, 13 Jun 2021 03:14:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Matthew Bauer <mjbauer95 <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 13 Jun 2021 03:14:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Matthew Bauer <mjbauer95 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: Andrea Corallo <akrl <at> sdf.org>
Subject: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily
 recompiles .eln (macOS)
Date: Sat, 12 Jun 2021 22:13:13 -0500
[Message part 1 (text/plain, inline)]
This is similar to bug#48497, but appears to still happen even after
commit 3f207753a0.

The basic problem is that the installed lisp path does not match either
of the search expressions in comp-el-to-eln-rel-filename, meaning that
native lisp needs to be recompiled needlessly.

The problem seems to come from PATH_REL_LOADSEARCH being set for me (on
macOS) to Contents/Resources/lisp, but the lisp files actually being
installed to
/nix/store/...-emacs-gcc-20210612.0/share/emacs/28.0.50/lisp (path
generated by Nix). As a result, comp-el-to-eln-rel-filename used the
filename comp-034d3699-516ce4bf.eln for comp.el.gz where 516ce4bf is the
md5sum of the contents of comp.el and 034d3699 is the md5sum of the full
path of comp.el, not of //emacs-lisp/comp.el (7672a6ed), which is what
Emacs installs.

To fix this, I propose using PATH_LOADSEARCH in addition to
PATH_REL_LOADSEARCH so that we can catch both types of macOS installs
(.app and unix). I’ve attached a patch which implements this, adding
relative and absolute loadsearch resolution.

- Matthew

[0001-Use-PATH_LOADSEARCH-to-get-absolute-path-of-native-c.patch (text/x-patch, inline)]
From 32022ee8d977196c72ad42d89d23142a6e59ff8e Mon Sep 17 00:00:00 2001
From: Matthew Bauer <mjbauer95 <at> gmail.com>
Date: Sat, 12 Jun 2021 00:37:28 -0500
Subject: [PATCH] Use PATH_LOADSEARCH to get absolute path of native comp

We need to so that
/usr/local/share/emacs/28.0.50/lisp/emacs-lisp/comp.el

becomes:

//emacs-lisp/comp.el

which is what we install eln files as.
---
 src/comp.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/comp.c b/src/comp.c
index 056d0860d8..8ccd99d583 100644
--- a/src/comp.c
+++ b/src/comp.c
@@ -4049,12 +4049,14 @@ DEFUN ("comp-el-to-eln-rel-filename", Fcomp_el_to_eln_rel_filename,
 
      As installing .eln files compiled during the build changes their
      absolute path we need an hashing mechanism that is not sensitive
-     to that.  For this we replace if match PATH_DUMPLOADSEARCH or
-     *PATH_REL_LOADSEARCH with '//' before computing the hash.  */
+     to that.  For this we replace if match PATH_DUMPLOADSEARCH,
+     PATH_REL_LOADSEARCH, or PATH_LOADSEARCH with '//' before
+     computing the hash.  */
 
   if (NILP (loadsearch_re_list))
     {
-      Lisp_Object sys_re =
+      Lisp_Object sys_abs_re = Fregexp_quote (build_string (PATH_LOADSEARCH "/"));
+      Lisp_Object sys_rel_re =
 	concat2 (build_string ("\\`[[:ascii:]]+"),
 		 Fregexp_quote (build_string ("/" PATH_REL_LOADSEARCH "/")));
       Lisp_Object dump_load_search =
@@ -4062,7 +4064,7 @@ DEFUN ("comp-el-to-eln-rel-filename", Fcomp_el_to_eln_rel_filename,
 #ifdef WINDOWSNT
       dump_load_search = Fw32_long_file_name (dump_load_search);
 #endif
-      loadsearch_re_list = list2 (sys_re, Fregexp_quote (dump_load_search));
+      loadsearch_re_list = list3 (sys_abs_re, sys_rel_re, Fregexp_quote (dump_load_search));
     }
 
   Lisp_Object lds_re_tail = loadsearch_re_list;
-- 
2.29.2


Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Sun, 13 Jun 2021 06:38:02 GMT) Full text and rfc822 format available.

Message #8 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Matthew Bauer <mjbauer95 <at> gmail.com>, Alan Third <alan <at> idiocy.org>
Cc: 48994 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50;
 Native compilation unnecessarily recompiles .eln (macOS)
Date: Sun, 13 Jun 2021 09:37:15 +0300
> From: Matthew Bauer <mjbauer95 <at> gmail.com>
> Date: Sat, 12 Jun 2021 22:13:13 -0500
> Cc: Andrea Corallo <akrl <at> sdf.org>
> 
> This is similar to bug#48497, but appears to still happen even after
> commit 3f207753a0.
> 
> The basic problem is that the installed lisp path does not match either
> of the search expressions in comp-el-to-eln-rel-filename, meaning that
> native lisp needs to be recompiled needlessly.
> 
> The problem seems to come from PATH_REL_LOADSEARCH being set for me (on
> macOS) to Contents/Resources/lisp, but the lisp files actually being
> installed to
> /nix/store/...-emacs-gcc-20210612.0/share/emacs/28.0.50/lisp (path
> generated by Nix). As a result, comp-el-to-eln-rel-filename used the
> filename comp-034d3699-516ce4bf.eln for comp.el.gz where 516ce4bf is the
> md5sum of the contents of comp.el and 034d3699 is the md5sum of the full
> path of comp.el, not of //emacs-lisp/comp.el (7672a6ed), which is what
> Emacs installs.
> 
> To fix this, I propose using PATH_LOADSEARCH in addition to
> PATH_REL_LOADSEARCH so that we can catch both types of macOS installs
> (.app and unix). I’ve attached a patch which implements this, adding
> relative and absolute loadsearch resolution.

Thanks.

Alan, any comments?

And could you explain to this macOS-illiterate why this mess happens
on macOS?

In any case, if this only happens on macOS, I see no reason to run the
additional code on other systems, it's just waste of cycles.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Sun, 13 Jun 2021 16:39:01 GMT) Full text and rfc822 format available.

Message #11 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48994 <at> debbugs.gnu.org, Matthew Bauer <mjbauer95 <at> gmail.com>, akrl <at> sdf.org
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Sun, 13 Jun 2021 17:37:55 +0100
On Sun, Jun 13, 2021 at 09:37:15AM +0300, Eli Zaretskii wrote:
> > From: Matthew Bauer <mjbauer95 <at> gmail.com>
> > Date: Sat, 12 Jun 2021 22:13:13 -0500
> > Cc: Andrea Corallo <akrl <at> sdf.org>
> > 
> > This is similar to bug#48497, but appears to still happen even after
> > commit 3f207753a0.
> > 
> > The basic problem is that the installed lisp path does not match either
> > of the search expressions in comp-el-to-eln-rel-filename, meaning that
> > native lisp needs to be recompiled needlessly.
> > 
> > The problem seems to come from PATH_REL_LOADSEARCH being set for me (on
> > macOS) to Contents/Resources/lisp, but the lisp files actually being
> > installed to
> > /nix/store/...-emacs-gcc-20210612.0/share/emacs/28.0.50/lisp (path
> > generated by Nix). As a result, comp-el-to-eln-rel-filename used the
> > filename comp-034d3699-516ce4bf.eln for comp.el.gz where 516ce4bf is the
> > md5sum of the contents of comp.el and 034d3699 is the md5sum of the full
> > path of comp.el, not of //emacs-lisp/comp.el (7672a6ed), which is what
> > Emacs installs.
> > 
> > To fix this, I propose using PATH_LOADSEARCH in addition to
> > PATH_REL_LOADSEARCH so that we can catch both types of macOS installs
> > (.app and unix). I’ve attached a patch which implements this, adding
> > relative and absolute loadsearch resolution.
> 
> Thanks.
> 
> Alan, any comments?

I suggested previously we handle this like we do the other install
paths (see ns_etc_path, ns_exec_path and ns_load_path in nsterm.m),
but Andrea didn't like that solution.

> And could you explain to this macOS-illiterate why this mess happens
> on macOS?

It's because we support both a relocatable application format and a
normal unix style install. In the .app case the path to the installed
files has to be configured at run-time (although I think Andrea used a
directory relative to the executable), but in the unix case it's
hard-coded.

FWIW, we will have exactly the same problems with GNUstep builds,
because they use the same .app format.

-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Sun, 13 Jun 2021 17:22:02 GMT) Full text and rfc822 format available.

Message #14 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 48994 <at> debbugs.gnu.org, mjbauer95 <at> gmail.com, akrl <at> sdf.org
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Sun, 13 Jun 2021 20:21:11 +0300
> Date: Sun, 13 Jun 2021 17:37:55 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: Matthew Bauer <mjbauer95 <at> gmail.com>, 48994 <at> debbugs.gnu.org,
> 	akrl <at> sdf.org
> 
> I suggested previously we handle this like we do the other install
> paths (see ns_etc_path, ns_exec_path and ns_load_path in nsterm.m),
> but Andrea didn't like that solution.

Can you point me to that discussion, please?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Sun, 13 Jun 2021 19:31:02 GMT) Full text and rfc822 format available.

Message #17 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48994 <at> debbugs.gnu.org, mjbauer95 <at> gmail.com, akrl <at> sdf.org
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Sun, 13 Jun 2021 20:30:13 +0100
On Sun, Jun 13, 2021 at 08:21:11PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 13 Jun 2021 17:37:55 +0100
> > From: Alan Third <alan <at> idiocy.org>
> > Cc: Matthew Bauer <mjbauer95 <at> gmail.com>, 48994 <at> debbugs.gnu.org,
> > 	akrl <at> sdf.org
> > 
> > I suggested previously we handle this like we do the other install
> > paths (see ns_etc_path, ns_exec_path and ns_load_path in nsterm.m),
> > but Andrea didn't like that solution.
> 
> Can you point me to that discussion, please?

There isn't much in the way of actual discussion.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47558#44
-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Mon, 14 Jun 2021 12:43:02 GMT) Full text and rfc822 format available.

Message #20 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 48994 <at> debbugs.gnu.org, mjbauer95 <at> gmail.com, akrl <at> sdf.org
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Mon, 14 Jun 2021 15:42:41 +0300
> Date: Sun, 13 Jun 2021 20:30:13 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: mjbauer95 <at> gmail.com, 48994 <at> debbugs.gnu.org, akrl <at> sdf.org
> 
> On Sun, Jun 13, 2021 at 08:21:11PM +0300, Eli Zaretskii wrote:
> > > Date: Sun, 13 Jun 2021 17:37:55 +0100
> > > From: Alan Third <alan <at> idiocy.org>
> > > Cc: Matthew Bauer <mjbauer95 <at> gmail.com>, 48994 <at> debbugs.gnu.org,
> > > 	akrl <at> sdf.org
> > > 
> > > I suggested previously we handle this like we do the other install
> > > paths (see ns_etc_path, ns_exec_path and ns_load_path in nsterm.m),
> > > but Andrea didn't like that solution.
> > 
> > Can you point me to that discussion, please?
> 
> There isn't much in the way of actual discussion.
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47558#44

Hmm... that problem was solved, though?  So how come it comes up once
again?

In the tree that you described in

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47558#23

can you where is each of the following:

  . the Emacs binary
  . the .pdmp file
  . the auxiliary executables (hexl, movemail)
  . the *.eln files

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"?  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?

The issue finding the *.eln files is tightly coupled with how Emacs
finds the .pdmp file, so we must consider these together to be sure
the solutions don't break.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Mon, 14 Jun 2021 18:33:01 GMT) Full text and rfc822 format available.

Message #23 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48994 <at> debbugs.gnu.org, mjbauer95 <at> gmail.com, akrl <at> sdf.org
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Mon, 14 Jun 2021 19:32:36 +0100
On Mon, Jun 14, 2021 at 03:42:41PM +0300, Eli Zaretskii wrote:
> > Date: Sun, 13 Jun 2021 20:30:13 +0100
> > From: Alan Third <alan <at> idiocy.org>
> > Cc: mjbauer95 <at> gmail.com, 48994 <at> debbugs.gnu.org, akrl <at> sdf.org
> > 
> > On Sun, Jun 13, 2021 at 08:21:11PM +0300, Eli Zaretskii wrote:
> > > > Date: Sun, 13 Jun 2021 17:37:55 +0100
> > > > From: Alan Third <alan <at> idiocy.org>
> > > > Cc: Matthew Bauer <mjbauer95 <at> gmail.com>, 48994 <at> debbugs.gnu.org,
> > > > 	akrl <at> sdf.org
> > > > 
> > > > I suggested previously we handle this like we do the other install
> > > > paths (see ns_etc_path, ns_exec_path and ns_load_path in nsterm.m),
> > > > but Andrea didn't like that solution.
> > > 
> > > Can you point me to that discussion, please?
> > 
> > There isn't much in the way of actual discussion.
> > 
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47558#44
> 
> Hmm... that problem was solved, though?  So how come it comes up once
> again?

It was solved for the .app use case, perhaps that broke the Unix-style
install case?

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.

> In the tree that you described in
> 
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47558#23
> 
> can you where is each of the following:
> 
>   . 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.

>   . 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.

> 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"?  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.

-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Mon, 14 Jun 2021 19:21:01 GMT) Full text and rfc822 format available.

Message #26 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 48994 <at> debbugs.gnu.org, mjbauer95 <at> gmail.com, akrl <at> sdf.org
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Mon, 14 Jun 2021 22:19:50 +0300
> Date: Mon, 14 Jun 2021 19:32:36 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: 48994 <at> debbugs.gnu.org, mjbauer95 <at> gmail.com, akrl <at> sdf.org
> 
> > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=47558#44
> > 
> > Hmm... that problem was solved, though?  So how come it comes up once
> > again?
> 
> It was solved for the .app use case, perhaps that broke the Unix-style
> install case?

Could very well be, see below.

> 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.

> >   . 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.

> >   . 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.

> > 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

?

> > 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Wed, 16 Jun 2021 18:26:01 GMT) Full text and rfc822 format available.

Message #29 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48994 <at> debbugs.gnu.org, mjbauer95 <at> gmail.com, akrl <at> sdf.org
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Wed, 16 Jun 2021 19:25:14 +0100
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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Wed, 16 Jun 2021 18:47:02 GMT) Full text and rfc822 format available.

Message #32 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 48994 <at> debbugs.gnu.org, mjbauer95 <at> gmail.com, akrl <at> sdf.org
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Wed, 16 Jun 2021 21:45:50 +0300
> Date: Wed, 16 Jun 2021 19:25:14 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: 48994 <at> debbugs.gnu.org, mjbauer95 <at> gmail.com, akrl <at> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Sat, 19 Jun 2021 17:05:03 GMT) Full text and rfc822 format available.

Message #35 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48994 <at> debbugs.gnu.org, mjbauer95 <at> gmail.com, akrl <at> sdf.org
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Sat, 19 Jun 2021 18:04:18 +0100
[Message part 1 (text/plain, inline)]
On Wed, Jun 16, 2021 at 09:45:50PM +0300, Eli Zaretskii wrote:
> > Date: Wed, 16 Jun 2021 19:25:14 +0100
> > From: Alan Third <alan <at> idiocy.org>
> > Cc: 48994 <at> debbugs.gnu.org, mjbauer95 <at> gmail.com, akrl <at> 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.

I think I did understand that. As far as I can tell that bit actually
works fine, as long as the pdmp file can be found the eln files can be
found.

> 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've attached a patch which, I hope, should solve these problems. I've
tried to align the code more with how other terms work, so I've
removed all the functions that calculate the various paths Emacs uses,
and replaced them with a single function that, given a relative path
inside the application bundle, can work out what the full path should
be, but will pass any absolute paths unchanged.

It's similar to w32_relocate, but not exactly the same, and I'm using
it in more places due to the app bundle layout being quite different.

I've also followed the w32 lead in changing how epaths.h is generated.
Basically I post-process it so that any paths that are internal to the
app bundle are converted to relative paths, so the above mentioned
function can deal with them.

> > >   . 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 think it's because of some hard-coding of things that was added to
work around problems in the app bundle code. They haven't been
suitably separated from the Unix style install code, so they end up
interfering with each other.

I think that now a Unix style install shouldn't be affected at all by
the app bundle code, but I'd like some extra testing by people who run
it that way before I'm fully convinced I've been successful in that.

> > > > 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?

The install location is known, but in the app bundle case the app can
be copied to anywhere and then the full paths will be different, so
they can't just be hard coded at install 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...

I tried, but it ended up quite a large patch as fixing one thing would
invariably break another, and I decided I had to sort out the epaths.h
situation before I could do much else, and most of the rest of the
patch is dealing with the fallout from that.

Anyway, it's attached. It's working here for the app bundle case and I
believe it should work well for the Unix style install, but I've not
tested that in any depth.

Matthew, could you please try the attached patch and see if it solves
your problems (or makes them worse!)?
-- 
Alan Third
[0001-Fix-NS-native-compilation-builds.patch (text/x-diff, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Tue, 22 Jun 2021 03:56:01 GMT) Full text and rfc822 format available.

Message #38 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Matthew Bauer <mjbauer95 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Eli Zaretskii <eliz <at> gnu.org>,
 48994 <at> debbugs.gnu.org, 
 Matthew Bauer <mjbauer95 <at> gmail.com>, Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Mon, 21 Jun 2021 22:55:40 -0500
[Message part 1 (text/plain, inline)]
> Matthew, could you please try the attached patch and see if it solves
> your problems (or makes them worse!)?

That fixes the problem! I had to make a small change for it to work though
(needed to add prefix & exec_prefix to nextstep/Makefile.in).

On Sat, Jun 19, 2021 at 12:04 PM Alan Third <alan <at> idiocy.org> wrote:

> On Wed, Jun 16, 2021 at 09:45:50PM +0300, Eli Zaretskii wrote:
> > > Date: Wed, 16 Jun 2021 19:25:14 +0100
> > > From: Alan Third <alan <at> idiocy.org>
> > > Cc: 48994 <at> debbugs.gnu.org, mjbauer95 <at> gmail.com, akrl <at> 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.
>
> I think I did understand that. As far as I can tell that bit actually
> works fine, as long as the pdmp file can be found the eln files can be
> found.
>
> > 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've attached a patch which, I hope, should solve these problems. I've
> tried to align the code more with how other terms work, so I've
> removed all the functions that calculate the various paths Emacs uses,
> and replaced them with a single function that, given a relative path
> inside the application bundle, can work out what the full path should
> be, but will pass any absolute paths unchanged.
>
> It's similar to w32_relocate, but not exactly the same, and I'm using
> it in more places due to the app bundle layout being quite different.
>
> I've also followed the w32 lead in changing how epaths.h is generated.
> Basically I post-process it so that any paths that are internal to the
> app bundle are converted to relative paths, so the above mentioned
> function can deal with them.
>
> > > >   . 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 think it's because of some hard-coding of things that was added to
> work around problems in the app bundle code. They haven't been
> suitably separated from the Unix style install code, so they end up
> interfering with each other.
>
> I think that now a Unix style install shouldn't be affected at all by
> the app bundle code, but I'd like some extra testing by people who run
> it that way before I'm fully convinced I've been successful in that.
>
> > > > > 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?
>
> The install location is known, but in the app bundle case the app can
> be copied to anywhere and then the full paths will be different, so
> they can't just be hard coded at install 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...
>
> I tried, but it ended up quite a large patch as fixing one thing would
> invariably break another, and I decided I had to sort out the epaths.h
> situation before I could do much else, and most of the rest of the
> patch is dealing with the fallout from that.
>
> Anyway, it's attached. It's working here for the app bundle case and I
> believe it should work well for the Unix style install, but I've not
> tested that in any depth.
>
> Matthew, could you please try the attached patch and see if it solves
> your problems (or makes them worse!)?
> --
> Alan Third
>
[Message part 2 (text/html, inline)]
[0001-Fix-NS-native-compilation-builds.patch (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Tue, 22 Jun 2021 08:33:02 GMT) Full text and rfc822 format available.

Message #41 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Matthew Bauer <mjbauer95 <at> gmail.com>
Cc: 48994 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Tue, 22 Jun 2021 09:32:34 +0100
On Mon, Jun 21, 2021 at 10:55:40PM -0500, Matthew Bauer wrote:
> > Matthew, could you please try the attached patch and see if it solves
> > your problems (or makes them worse!)?
> 
> That fixes the problem! I had to make a small change for it to work though
> (needed to add prefix & exec_prefix to nextstep/Makefile.in).

!?

As far as I'm aware nextstep/Makefile shouldn't need to know about the
prefix because it's not relevant to that type of install...

What configure flags are you using? (They should be listed at the top
of configure.log.)
-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Tue, 22 Jun 2021 16:53:02 GMT) Full text and rfc822 format available.

Message #44 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Matthew Bauer <mjbauer95 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Matthew Bauer <mjbauer95 <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 
 48994 <at> debbugs.gnu.org, Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Tue, 22 Jun 2021 11:51:57 -0500
[Message part 1 (text/plain, inline)]
> !?

> As far as I'm aware nextstep/Makefile shouldn't need to know about the
> prefix because it's not relevant to that type of install...

> What configure flags are you using? (They should be listed at the top
> of configure.log.)

There's probably a better to way to fix it - my familiarity with autoconf
is not great.

But in nextstep/Makefile we get this line:

ns_applibexecdir = ${exec_prefix}/libexec
>

and exec_prefix undefined without defining prefix & exec_prefix.

On Tue, Jun 22, 2021 at 3:32 AM Alan Third <alan <at> idiocy.org> wrote:

> On Mon, Jun 21, 2021 at 10:55:40PM -0500, Matthew Bauer wrote:
> > > Matthew, could you please try the attached patch and see if it solves
> > > your problems (or makes them worse!)?
> >
> > That fixes the problem! I had to make a small change for it to work
> though
> > (needed to add prefix & exec_prefix to nextstep/Makefile.in).
>
> !?
>
> As far as I'm aware nextstep/Makefile shouldn't need to know about the
> prefix because it's not relevant to that type of install...
>
> What configure flags are you using? (They should be listed at the top
> of configure.log.)
> --
> Alan Third
>
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Tue, 22 Jun 2021 17:01:02 GMT) Full text and rfc822 format available.

Message #47 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Matthew Bauer <mjbauer95 <at> gmail.com>
Cc: 48994 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Tue, 22 Jun 2021 17:59:59 +0100
On Tue, Jun 22, 2021 at 11:51:57AM -0500, Matthew Bauer wrote:
> > !?
> 
> > As far as I'm aware nextstep/Makefile shouldn't need to know about the
> > prefix because it's not relevant to that type of install...
> 
> > What configure flags are you using? (They should be listed at the top
> > of configure.log.)
> 
> There's probably a better to way to fix it - my familiarity with autoconf
> is not great.
> 
> But in nextstep/Makefile we get this line:
> 
> ns_applibexecdir = ${exec_prefix}/libexec
> >
> 
> and exec_prefix undefined without defining prefix & exec_prefix.

But you are building with the flag --disable-ns-self-contained?

If so there's no need for nextstep/Makefile to do anything, so it
shouldn't matter. I suppose we probably want to avoid generating that
makefile, or not call it, or something... I'm not sure.
-- 
Alan Third




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Tue, 22 Jun 2021 17:26:02 GMT) Full text and rfc822 format available.

Message #50 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Matthew Bauer <mjbauer95 <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>,
 48994 <at> debbugs.gnu.org, Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Tue, 22 Jun 2021 18:24:56 +0100
[Message part 1 (text/plain, inline)]
On Tue, Jun 22, 2021 at 05:59:59PM +0100, Alan Third wrote:
> If so there's no need for nextstep/Makefile to do anything, so it
> shouldn't matter. I suppose we probably want to avoid generating that
> makefile, or not call it, or something... I'm not sure.

Turns out there's another variable that should only be set when
building the app.

Please try the attached patch.
-- 
Alan Third
[v2-0001-Fix-NS-native-compilation-builds.patch (text/plain, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Tue, 22 Jun 2021 23:02:02 GMT) Full text and rfc822 format available.

Message #53 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Matthew Bauer <mjbauer95 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Matthew Bauer <mjbauer95 <at> gmail.com>,
 Eli Zaretskii <eliz <at> gnu.org>, 
 48994 <at> debbugs.gnu.org, Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Tue, 22 Jun 2021 18:01:25 -0500
[Message part 1 (text/plain, inline)]
> Turns out there's another variable that should only be set when
> building the app.

> Please try the attached patch.

That works for me !

So previously the nextstep/Emacs.app was getting generated even
with --disable-ns-self-contained. I think that's fine to not build in
this case - in fact it duplicates the Emacs executable - but just a note
that it kind of changes things for packages. I have a fix for Nixpkgs
(which previously installed nexstep/Emacs.app), but I think
homebrew-emacs-plus would also be effected:

https://github.com/d12frosted/homebrew-emacs-plus

On Tue, Jun 22, 2021 at 12:24 PM Alan Third <alan <at> idiocy.org> wrote:

> On Tue, Jun 22, 2021 at 05:59:59PM +0100, Alan Third wrote:
> > If so there's no need for nextstep/Makefile to do anything, so it
> > shouldn't matter. I suppose we probably want to avoid generating that
> > makefile, or not call it, or something... I'm not sure.
>
> Turns out there's another variable that should only be set when
> building the app.
>
> Please try the attached patch.
> --
> Alan Third
>
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Wed, 23 Jun 2021 16:00:03 GMT) Full text and rfc822 format available.

Message #56 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Matthew Bauer <mjbauer95 <at> gmail.com>
Cc: 48994 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Andrea Corallo <akrl <at> sdf.org>
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Wed, 23 Jun 2021 16:59:31 +0100
[Message part 1 (text/plain, inline)]
On Tue, Jun 22, 2021 at 06:01:25PM -0500, Matthew Bauer wrote:
> > Turns out there's another variable that should only be set when
> > building the app.
> 
> > Please try the attached patch.
> 
> That works for me !
> 
> So previously the nextstep/Emacs.app was getting generated even
> with --disable-ns-self-contained. I think that's fine to not build in
> this case - in fact it duplicates the Emacs executable - but just a note
> that it kind of changes things for packages. I have a fix for Nixpkgs
> (which previously installed nexstep/Emacs.app), but I think
> homebrew-emacs-plus would also be effected:
> 
> https://github.com/d12frosted/homebrew-emacs-plus

This sounds like madness to me, but I see it's a supported
configuration mentioned in our install files.

So, attempt three attached!
-- 
Alan Third
[v3-0001-Fix-NS-native-compilation-builds.patch (text/x-diff, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Wed, 23 Jun 2021 20:47:02 GMT) Full text and rfc822 format available.

Message #59 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Matthew Bauer <mjbauer95 <at> gmail.com>
To: Alan Third <alan <at> idiocy.org>, Matthew Bauer <mjbauer95 <at> gmail.com>
Cc: 48994 <at> debbugs.gnu.org
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Wed, 23 Jun 2021 15:46:12 -0500
[Message part 1 (text/plain, inline)]
That works for me! No apparent issues.

On Wed, Jun 23, 2021 at 10:59 AM Alan Third <alan <at> idiocy.org> wrote:

> On Tue, Jun 22, 2021 at 06:01:25PM -0500, Matthew Bauer wrote:
> > > Turns out there's another variable that should only be set when
> > > building the app.
> >
> > > Please try the attached patch.
> >
> > That works for me !
> >
> > So previously the nextstep/Emacs.app was getting generated even
> > with --disable-ns-self-contained. I think that's fine to not build in
> > this case - in fact it duplicates the Emacs executable - but just a note
> > that it kind of changes things for packages. I have a fix for Nixpkgs
> > (which previously installed nexstep/Emacs.app), but I think
> > homebrew-emacs-plus would also be effected:
> >
> > https://github.com/d12frosted/homebrew-emacs-plus
>
> This sounds like madness to me, but I see it's a supported
> configuration mentioned in our install files.
>
> So, attempt three attached!
> --
> Alan Third
>
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#48994; Package emacs. (Wed, 23 Jun 2021 20:49:01 GMT) Full text and rfc822 format available.

Message #62 received at 48994 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Matthew Bauer <mjbauer95 <at> gmail.com>
Cc: 48994 <at> debbugs.gnu.org
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Wed, 23 Jun 2021 21:48:11 +0100
Thanks!

I'll leave it a few days before pushing it just in case anyone else
spots anything wrong with it.

On Wed, Jun 23, 2021 at 03:46:12PM -0500, Matthew Bauer wrote:
> That works for me! No apparent issues.
> 
> On Wed, Jun 23, 2021 at 10:59 AM Alan Third <alan <at> idiocy.org> wrote:
> 
> > On Tue, Jun 22, 2021 at 06:01:25PM -0500, Matthew Bauer wrote:
> > > > Turns out there's another variable that should only be set when
> > > > building the app.
> > >
> > > > Please try the attached patch.
> > >
> > > That works for me !
> > >
> > > So previously the nextstep/Emacs.app was getting generated even
> > > with --disable-ns-self-contained. I think that's fine to not build in
> > > this case - in fact it duplicates the Emacs executable - but just a note
> > > that it kind of changes things for packages. I have a fix for Nixpkgs
> > > (which previously installed nexstep/Emacs.app), but I think
> > > homebrew-emacs-plus would also be effected:
> > >
> > > https://github.com/d12frosted/homebrew-emacs-plus
> >
> > This sounds like madness to me, but I see it's a supported
> > configuration mentioned in our install files.
> >
> > So, attempt three attached!
> >

-- 
Alan Third




Reply sent to Alan Third <alan <at> idiocy.org>:
You have taken responsibility. (Sat, 26 Jun 2021 09:39:01 GMT) Full text and rfc822 format available.

Notification sent to Matthew Bauer <mjbauer95 <at> gmail.com>:
bug acknowledged by developer. (Sat, 26 Jun 2021 09:39:01 GMT) Full text and rfc822 format available.

Message #67 received at 48994-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Matthew Bauer <mjbauer95 <at> gmail.com>
Cc: 48994-done <at> debbugs.gnu.org
Subject: Re: bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation
 unnecessarily recompiles .eln (macOS)
Date: Sat, 26 Jun 2021 10:38:19 +0100
I've pushed it to master.

Thanks!

On Wed, Jun 23, 2021 at 03:46:12PM -0500, Matthew Bauer wrote:
> That works for me! No apparent issues.
> 
> On Wed, Jun 23, 2021 at 10:59 AM Alan Third <alan <at> idiocy.org> wrote:
> 
> > On Tue, Jun 22, 2021 at 06:01:25PM -0500, Matthew Bauer wrote:
> > > > Turns out there's another variable that should only be set when
> > > > building the app.
> > >
> > > > Please try the attached patch.
> > >
> > > That works for me !
> > >
> > > So previously the nextstep/Emacs.app was getting generated even
> > > with --disable-ns-self-contained. I think that's fine to not build in
> > > this case - in fact it duplicates the Emacs executable - but just a note
> > > that it kind of changes things for packages. I have a fix for Nixpkgs
> > > (which previously installed nexstep/Emacs.app), but I think
> > > homebrew-emacs-plus would also be effected:
> > >
> > > https://github.com/d12frosted/homebrew-emacs-plus
> >
> > This sounds like madness to me, but I see it's a supported
> > configuration mentioned in our install files.
> >
> > So, attempt three attached!
> >

-- 
Alan Third




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 24 Jul 2021 11:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 247 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.