bug#44128: [feature/native-comp]

[Eli Zaretskii]

> Cc: akrl@sdf.org, jonas@bernoul.li, 44128@debbugs.gnu.org, eli@gnu.org
> From: Phil Sainty <psainty@orcon.net.nz>
> Date: Fri, 16 Apr 2021 09:52:59 +1200
> 
> On 16/04/21 2:42 am, Eli Zaretskii wrote:
> >> $ emacs --version
> >> emacs: could not resolve realpath of "emacs": No such file or directory
> >> $ touch emacs
> >> $ emacs --version
> >> emacs: 
> >> /tmp/../native-lisp/28.0.50-abd7aa58/preloaded/window-0d1b8b93-581f9fcd.eln:
> >>  cannot open shared object file: No such file or directory
> >
> > That's Emacs trying to see if it is run uninstalled, so I see no
> > problem here.  What exactly do you think is wrong with this, again?
> 
> The first problem is that it's currently not possible to start
> emacs if you're in a directory which contains a file or directory
> called 'emacs'.

That's not relevant to the message above; the failure related to the
presence of a directory or file named 'emacs' is a bug that will be
solved.

> The second problem is that this type of behaviour feels rather
> like something you mentioned earlier: having "." in your PATH,
> which is widely considered a bad idea.

But that ship has sailed long, long, LONG ago: Emacs was always
looking for its Lisp files in the directory "../lisp" relative to
where it was invoked since about forever.  How else can we support
both installed and uninstalled invocations?  When Emacs is run
uninstalled, the Lisp files can be anywhere on the system.  The only
difference is that now we _also_ look for the *.eln files in a similar
fashion.

IOW, Emacs always tries the configured installation directory first;
if the files are not there, it tries relative to the invocation
directory on the assumption that we are running uninstalled.  And that
is why you see the error message above.  There's nothing wrong with
the message per se, and once the problem with finding the files in
your case is solved, the message will disappear.

> In future, once this feature is merged, many people will have
> multiple local installs of various native-comp-enabled versions,
> and might be moving between them and/or working on them.  If
> Emacs then tried to run code for the version in the CWD even if
> the executable that was invoked was for a different install, that
> would be very surprising (and potentially very difficult for the
> user to notice).

The *.eln files include various hashes in their file names that
prevent loading of a mismatched .eln file.  This should support having
several variants of a .eln file, corresponding to several Emacs
binaries, in the same directory.  So I don't quite see the danger that
you have in mind.

> I do see the hashes in the filenames, so maybe that scenario is
> already avoided, if the eln filenames are unique to the version
> of Emacs?

Yes.

> This "looking in the CWD" behaviour still feels wrong to me, though.
> Are there other existing ways in which Emacs changes its behaviour
> based on the CWD?

See above: we were doing that since day one, more or less.