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

[Eli Zaretskii]

> Date: Wed, 16 Jun 2021 19:25:14 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: 48994@debbugs.gnu.org, mjbauer95@gmail.com, akrl@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.