Re: Suppressing native compilation (short and long term)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: rlb@defaultvalue.org,  tomas@tuxteam.de,  emacs-devel@gnu.org
> Date: Mon, 03 Oct 2022 14:33:09 -0400
> 
> >> And the issue is not subprocesses per se, but it's extra processing that
> >> happens outside of the control of the user.
> > How do you mean "outside of the control of the user"?  The user causes
> > it by loading a feature.
> 
> When a user loads a feature, this request doesn't say explicitly "and
> native compile the file".  And there is no direct way to "just load this
> package without compiling it".  So the compilation is not really under
> the control of the user.
> 
> I don't think users know, when they load a feature, if it's the first
> time they loaded this feature in this version of Emacs, so by and large
> they can't predict when the compilation does happen.

It just takes getting used to, that's all.

> > How is that different from any other command that uses a subprocess
> > under the hood?
> 
> It's different in that for those other commands, the users cannot get
> the result they want without running that subprocess, so even if they're
> not fully aware of it, they do have some vague idea it's inevitably
> going to happen.
> 
> In contrast, the compilation is not indispensable, (so much so that the
> past it never happened).

So native-compilation is "guilty" because it can be disabled? ;-)

> > On my system, I don't see any warnings.
> 
> That's presumably because you stick to the bundled packages (where we've
> managed to keep a "no compilation warnings" state for the last few
> years) or the few third party packages which are careful enough to
> eliminate all warnings.
> 
> The rise of ELPA has removed most of the cases where native compilation
> will miscompile files (because ELPA forces the .el files to be compiled
> in a "standard" way rather than using ad-hoc Makefile rules which the
> native compiler cannot and does not try to reproduce), but compilation
> warnings are still very common (the situation is improving, tho, and
> arguably the warnings popping up out of the blue during lazy native
> compilation may prove to be a good way to convince more package authors
> to clean up their act).

So this, too, is extremely temporary, and will disappear soon enough,
at least in popular packages.