Re: [feature/dll-only-windows] A new windows build, comments wanted

[Andrea Corallo]

Phillip Lord <phillip.lord@russet.org.uk> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Phillip Lord <phillip.lord@russet.org.uk> writes:
>>
>>>
>>> I think there are two hairs here. Having an emacs compiled with
>>> nativecomp behave cleanly if libgccjit is not available at runtime.
>>
>> Right, at this stage this should be easy to implement (on Windows).
>>
>>> And having a runtime mechanism for switching nativecomp of totally
>>> even if it is compiled in.
>>
>> We should define "switching nativecomp of" and the triggering mechanism,
>> this might be already implmentented.
>
>
>>From a user perspective, I think that there are two reasons we might
> want to switch off native-comp.
>
> The first is because it's broken or providing buggy behaviour. In the
> extreme, and if I understand the build process fully, I guess this is
> impossible to switch of in a binary distribution, because some
> native-comp happens before dumping. Other than that, we can "switch off"
> native-comp by just deleting the *eln files, right, or otherwise
> preventing their loading. In practice, I think this is a minor
> motivation; if we discover bugs in the native-comp, they would be fixed
> by making another release.

Hi Phillip,

ATM we can prevent Emacs loading .eln file in place of .elc
automatically setting `load-no-native' to t.

> The second reason is that the initial compilation takes quite a lot of
> CPU. I wouldn't like that to happen while my laptop where in battery
> power, for instance. At the moment, it's possible to drop the number of
> jobs that native-comp uses. I don't think that there is a way to drop
> this to zero at the moment. Probably, we need that.

Setting `comp-deferred-compilation' to nil should stop any automatic
attempt of compiling asycronousy.

Maybe these two settings are already covering most of these needs?

Regards

  Andrea