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

[Alan Third]

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