[Top][All Lists]

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

Re: Suppressing native compilation (short and long term)

From: Andrea Corallo
Subject: Re: Suppressing native compilation (short and long term)
Date: Wed, 05 Oct 2022 16:04:46 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>> This is not the case at all, please trust me, your changeset does two
>> things:
>> 1- change the name a knob, but it goes from a maybe un-intuitive one to
>>    just (as explained) a plain wrong one.
> It goes from an un-intuitive (and undocumented) one to an
> intuitively-named (and documented) one.

The documentation topic is orthogonal, you could have improved
`native-comp-deferred-compilation' documentation if you wanted.

The naming went first to `inhibit-native-compilation', this was really
just sooo wrong in so many levels :/ So many as many knobs we have to
control and disable different parts of the native compiler.  I can't
really think of one understanding all this machinery and then picking up
this name sorry, I can't.

Then the name became `inhibit-automatic-native-compilation' that is
fortunately just wrong on one level :/

The original name was the name of one of the two mechanisms concurring
to native compilation, that is the reason why it was just not called

> In my opinion, the old variable
> is just as wrong as the current one (because it seemed to imply that
> compilation would be immediate instead of deferred).

`native-comp-deferred-compilation' implies that native compilation can
happen deferred.  But anyway this name was reviewed and the name used
here countless times for long time.  Changing it with zero discussion is
just not good cooperation spirit, sorry.  You can think of it
differently but you just risk to remain alone doing development.

>> 2- add a mechanism that (as explained) cannot help with the user request
>>    in this discussion at all.
> And I've explained twice now that 2 is wrong -- these changes do exactly
> what was requested:
>   1) It allows testing without writing to $HOME.  (This has nothing to
>   do with --batch -- testing happens in interactive Emacsen, too.)

The user request is for non interactive sessions AFAIU.  And still I've
to understand exactly what the user wants to solve.  Most importantly I
feel I'm not alone here.

>   2) It allows people to run an AOT Emacs without triggering further
>   compilation.

Sorry as changeset I meant 5fec9182db + f97993ee66.  I'm not against

> If you have a suggestion for an alternative change that achieves these
> two things, I'm all ears.  (But if your objection is "people shouldn't
> want those two things", I'm down to just two ears again.)

Again 5fec9182db + f97993ee66 are IMO not useful / wrong, they were not
discussed and are just a step backward.  The best change I can suggest
is to revert them now.



reply via email to

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