bug#45751: [feature/native-comp] emacs keeps running 100% of CPU

["Édouard Debry" <edouard.debry@gmail.com>]

On lun., janv. 11 2021, Édouard Debry wrote:
> On lun., janv. 11 2021, Eli Zaretskii wrote:
>>> Date: Sun, 10 Jan 2021 20:14:53 +0000
>>> Cc: 45751@debbugs.gnu.org
>>> From: Andrea Corallo via "Bug reports for GNU Emacs,
>>>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
>>>  > Compiling
>>> > /home/edouard/.emacs.d/elpa/color-theme-sanityinc-solarized-20200805.603/color-theme-sanityinc-solarized.el...
>>> I see a similar issue with sanityinc-tomorrow.el, the 
>>> compilation is way
>>> slower than any other one but it completes eventually.  I 
>>> guess is the
>>> same issue you see and with sufficient RAM also 
>>> sanityinc-solarized
>>> should complete.
>>> In case of of sanityinc-tomorrow I think is because of
>>> `color-theme-sanityinc-tomorrow'.  This is a single function 
>>> that after
>>> macro expansion becomes enormous.
>>> We need to make the compiler robust against these corner 
>>> cases, I'll
>>> have a look this week into adding some logic for that.
>>
>> Maybe we should have a "no-native-compile" cookie for these 
>> cases.
>> After all, compiling a theme will not really speed up anything
>> important, right?
>
> This is more or less what I advocated with a native compile 
> blacklist.
>
> At the moment, it would help me if it is possible to toggle 
> native compilation.
> In my config file there is :
>
> (setq package-native-compile t)
>
> If I set it to nil, does it mean that, on startup, emacs will 
> not try to natively
> compile
> any packages ?

Answering to my own question, it seems that no. Is there an emacs 
command to kill the
native compiling process ? It seems that closing the log buffer 
has this effect, but there
is probably a better way.