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

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

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

No you are not, once we bootstrap and dump a native compiled Emacs
there's no way we can undone it and get the equivalent one with only
bytecode.

Other than I can mention some knobs we already have that might partially
help here:

- inibith the automatic native compilation of new code with
 `comp-deferred-compilation'.

- prevent .eln from being loaded in place of bytecode with
  `load-no-native'.

Thanks

  Andrea