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

[Phil Sainty <psainty@orcon.net.nz>]

> Eli Zaretskii <eliz@gnu.org> writes:
>> 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).

That sounds like a good solution (and maybe one which could be wrapped
up under a new option, if the --with-native-compilation build process
automatically generated both *.pdmp files, and Emacs knows what they
both are).


>> 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.

I guess time will tell.  My feeling was that if end users encounter
native-comp bugs that are not trivial for the maintainers to reproduce
(e.g. some collection of third-party packages is involved), then it
might be super helpful to be able to ask them to test with native-comp
disabled, to confirm whether or not that is a factor.  As many users
will, in future, be running a native-comp Emacs which has been pre-
packaged for their OS, they will not easily be able to perform such a
test without such a feature.

It would definitely be a "nice to have".  However as it's evidentially
non-trivial to support this feature, I don't know whether the effort
would actually prove worthwhile.


>> (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.

I did think of that, but my feeling was that it's just not the same
thing as inhibiting the native-compilation entirely.  But as an existing
alternative which would probably do the job in most cases, it's hard to
argue with.


On 27/04/21 2:10 am, Andrea Corallo wrote:
> Other than I can mention some knobs we already have that might partially
> help here:
> 
> - prevent .eln from being loaded in place of bytecode with
>   `load-no-native'.

Yes, that's good to know about.  I see now that "apropos-variable native"
is very useful (my bad for not thinking of that earlier).

That var should definitely be noted in the manual once we have some in-
built docs for this; but in the meantime it might be very helpful to
update https://akrl.sdf.org/gccemacs.html with a collection of the ways
that users can tweak/test this feature?


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

This, OTOH, doesn't use the "native" keyword at all.

Could we rename any such variables so that everything to do with
native compilation includes the word "native"?  That's a dramatically
more specific term than "compilation", so it would seem good if it
was an easy way to find/identify the native-comp options.


-Phil