Re: Suppressing native compilation (short and long term)

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Lars Ingebrigtsen <larsi@gnus.org>,
>   liliana.prikler@gmail.com,  rlb@defaultvalue.org,  emacs-devel@gnu.org
> Date: Fri, 14 Oct 2022 23:14:41 -0400
> 
> > Dumb question: can't we just run the spawned compilation processes with
> > --no-site-file?
> 
> For trampolines, I guess that should work since they shouldn't depend on
> local customizations.

But it will potentially cause other issues, because the environment in
which the compiling Emacs sub-process run is different from that of
the Emacs session which triggered the compilation?  So we could have
warnings and errors in the compilation process due to stuff being
undefined etc.?  Isn't this why we do read the init files in the async
sub-process which performs the compilation?

> Of course, a tempting alternative is to resort to
> "binary hacking", i.e. compile *one* template-trampoline and then
> generate all every other trampoline by copying that template and
> patching the right "stuff" into it.  That would save us from running the
> compiler to generate the trampolines (i.e. it would let us behave
> correctly on Windows even when GCC/libgccjit is not found at run time),
> but it would force us to write architecture-dependent code to patch the
> binary template.

I don't think we should depend on architecture-dependent code.  It
would mean we don't support new platforms until someone writes such
code for them, for starters.  It's against our development tendencies
for the past 10 years at least.