[Top][All Lists]

[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, 05 Nov 2022 08:44:54 +0200

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 5 Nov 2022 02:09:55 +0100
> Cc: Andrea Corallo <akrl@sdf.org>, Eli Zaretskii <eliz@gnu.org>, 
> rlb@defaultvalue.org, 
>       monnier@iro.umontreal.ca, david@tethera.net, emacs-devel@gnu.org
> In my setup, I call `startup-redirect-eln-cache' in init.el because I don't
> want the cache in my .emacs.d/.

Why do you need to do that?  What's the problem with having the
eln-cache under your ~/.emacs.d/?

> However, when I'm using -Q to test something, I do
> M-x whatever-which-loads-a-module and end up getting an unwanted
> .emacs.d/eln-cache/

If this testing is for the purposes of Emacs development, then my
suggestion is to have a separate build configured without native
compilation support.  That's what I do.

> So either a --no-native flag (setting `inhibit-automatic-native-compilation',
> and perhaps `load-no-native', to t) or having such behavior in -Q would be
> quite helpful.
> Yes, I can define an alias to use
> --eval "(setq inhibit-automatic-native-compilation t)"
> I already have. Still, I regularly forget it and default to emacs -Q.

So it's just a matter of getting used to using the alias, and will be
solved with time.

> So, FWIW, I agree with your sentiment that -Q has no single defining goal
> other than "do not do unnecessary things, please", and inhibiting native
> comp would fit quite well.

I disagree.  We have too many knobs already, so adding a new one
without a good reason would be a mistake in the long run.

reply via email to

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