Re: Suppressing native compilation (short and long term)

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

Yes, when compiling actual ELisp files.  I'm talking about compiling the
trampolines: that's different because it's just compiling a fixed chunk
of code *we* write.

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

I know, I know.  From a technical point of view, it's The Right Thing to
do, I think, tho: it will eliminate all the other issues surrounding
trampolines (e.g. disk space to store trampolines, dependence on
libgccjit for the creation of those trampolines, fork bombs) and will be
much more efficient both in CPU time and memory use (we don't care too
much, because trampolines are hopefully not too frequents, so we live
with them being quite inefficient in the time to create them (and set
them up, via dyn-linking) and in their memory use).

But yes, the architecture-dependence is a serious problem, which is why
we've so far avoided that solution.


        Stefan