GNU bug report logs -
#48025
28.0.50; Add an invocation option to inhibit native-compilation functionality
Previous Next
Reported by: Phil Sainty <psainty <at> orcon.net.nz>
Date: Mon, 26 Apr 2021 05:53:01 UTC
Severity: normal
Tags: wontfix
Found in version 28.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Phil Sainty <psainty <at> orcon.net.nz>
>> Date: Mon, 26 Apr 2021 17:52:52 +1200
>> Cc: Andrea Corallo <akrl <at> 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
This bug report was last modified 3 years and 16 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.