bug#48025: 28.0.50; Add an invocation option to inhibit native-compilation functionality

[Eli Zaretskii <eliz@gnu.org>]

> From: Phil Sainty <psainty@orcon.net.nz>
> Date: Mon, 26 Apr 2021 17:52:52 +1200
> Cc: Andrea Corallo <akrl@sdf.org>
> 
> Now that the native-compilation feature is merged, it would be very
> useful to be able to build Emacs --with-native-compilation but be
> able to choose to inhibit that functionality at start time via a
> command-line option such as 'emacs --no-native-compilation', which
> would cause Emacs to load/execute only .el and .elc files.
> 
> This will enable users to easily compare functionality with and
> without native-compilation, so that native-compilation bugs can be
> more easily identified and reproduced without requiring people to
> maintain more than one build of Emacs in order to test how the
> traditional interpreters behave.
> 
> I'm not sure if/how this ties in with the portable dumper.  Perhaps
> there are .eln files included in the dump?  If so, perhaps the dump
> would need to include both the .elc and the .eln code, and choose
> which to use based on the new option.

Andrea will correct me, but I think this is not trivial to implement,
not even close.  Indeed, the contents of the pdumper file is different
in the two cases, and I see no easy way of having both byte-compiled
and native-compiled stuff live together in the same dump (they define
the same functions, remember?).

We could perhaps provide a special value of --temacs= switch to
temacs, so that the same temacs executable could be dumped into 2
different *.pdmp files, one with natively-compiled preloaded stuff,
the other with byte-compiled stuff; then users could use the existing
option --dump-file= to start Emacs with the non-standard pdumper file
(they will also need to set comp-deferred-compilation to nil to
prevent any run-time native-compilations once Emacs starts).

But frankly, I would hesitate to complicate Emacs even for the latter
possibility.  What you ask for doesn't seem to be a user-level
feature, it is mainly important for Emacs developers, and those can
always build 2 separate binaries (e.g., I already did).  Building a
differently-configured Emacs, even from the same Git repository, is so
easy that I don't really see a justification for a feature like you
describe.

(As for reproducing problems easily: it isn't hard to run the
interpreted or byte-compiled Lisp, if you can identify the relevant
Lisp files involved in the problem: just load them manually.  Andrea,
am I missing something?)