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

[Eli Zaretskii <eliz@gnu.org>]

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

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.