emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suppressing native compilation (short and long term)


From: Eli Zaretskii
Subject: Re: Suppressing native compilation (short and long term)
Date: Sat, 15 Oct 2022 19:26:53 +0300

> From: Andrea Corallo <akrl@sdf.org>
> Cc: larsi@gnus.org, monnier@iro.umontreal.ca, liliana.prikler@gmail.com,
>         rlb@defaultvalue.org, emacs-devel@gnu.org
> Date: Sat, 15 Oct 2022 15:19:40 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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?

Yes, this is more-or-less what I thought you had in mind.  I guess
setting of this new variable for the forked subprocesses will be via
the command line?

I think it's a fine solution, but either comp-spawned-compilation
should be renamed to comp-no-spawn, or its value in the forked Emacs
processes should be nil...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]