bug#48994: 28.0.50; [PATCH] 28.0.50; Native compilation unnecessarily recompiles .eln (macOS)

[Alan Third <alan@idiocy.org>]

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@idiocy.org>
> > Cc: mjbauer95@gmail.com, 48994@debbugs.gnu.org, akrl@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@idiocy.org>
> > > > Cc: Matthew Bauer <mjbauer95@gmail.com>, 48994@debbugs.gnu.org,
> > > > 	akrl@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