Re: Suppressing native compilation (short and long term)

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>, monnier@iro.umontreal.ca,
>>         liliana.prikler@gmail.com, rlb@defaultvalue.org, emacs-devel@gnu.org
>> Date: Fri, 14 Oct 2022 23:20:43 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> .elc -> .eln generation is off, but trampolines are on, and comp.el
>> >> forks an Emacs to generate those, too, I think?  So if the forked Emacs
>> >> also needs to generate the same trampoline, you have an infinite
>> >> recursion fork bomb.
>> >
>> > Andrea, how can we prevent that?
>> 
>> Dumb question: can't we just run the spawned compilation processes with
>> --no-site-file?
>
> I don't think I understand how --no-site-file could help.  Are you
> assuming that such advises could only come from sit-init files?

Yes this was the assumption.

> If
> so, I'm sure they could come from other sources, or what am I missing?

I think you are not missing much... as not said.

>> Other option is to break circularity with an ad-hoc global variable set
>> in the spawned process.  I've a cooked patch for that but no energy left
>> to test it tonight.  If that's the preferred way I can test and push it
>> tomorrow.
>
> Maybe it's preferable, but I'm not sure the idea of the change I get
> from your short description is what you really meant.  Can you tell
> more about that?  What ad-hoc variables did you have in mind, and how
> would we use them in this case to prevent infinite forking of
> sub-processes?

We define a new variable say `comp-spawned-compilation' and we set it to
t in all spawed compilation sub processes.  Then when we need a
trampoline:

- If it's available we load it.
- If it's not and `comp-spawned-compilation' is nil we compile it and
  load it, otherwise if `comp-spawned-compilation' is t we just do
  nothing (so we break circularity).

WDYT?

Bests

  Andrea