[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: Sun, 02 Oct 2022 22:15:21 +0300

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  Eli Zaretskii
>  <eliz@gnu.org>,  david@tethera.net,  emacs-devel@gnu.org,  akrl@sdf.org
> Date: Sun, 02 Oct 2022 21:08:15 +0200
> Rob Browning <rlb@defaultvalue.org> writes:
> > At the top level, we wanted a way to avoid writing to HOME during
> > packaging, testing, installs (in this case, it's the .eln files, now
> > that we've enabled native compilation).
> >
> > That could be handled by some way to turn off native compilation, or by
> > some way to comprehensively divert those writes to another location
> > (e.g. temp dir).  Either is fine, though we'd originally thought the
> > former might make things a bit easier.
> Yeah, I think the former is both easier to implement and easier for
> users.

The request that started this discussion was not from users, it was
from distributors.

If we want to consider providing (yet another) user option for
disabling native compilation, then we should:

  . understand why and in which situations they may need it
  . what exactly needs to be disabled (e.g.: do you want to disable
    loading the existing *.eln files?)
  . understand why the existing options don't already provide

I object to introducing new options before we do the above and
understand well what we are talking about.

> So I'm thinking of introducing a user option like
> `native-compile-inhibit', which will make Emacs skip the native-comp
> machinery when loading .elc files.  It will default to nil, of course,
> but perhaps it would be convenient to make it depend on an environment
> variable like "NATIVE_COMPILE_INHIBIT"?  Then users (and the Debian
> build system) could say "NATIVE_COMPILE_INHIBIT=true emacs ..." when
> doing testing etc?  Would that fit your use case?

Their use case is not the use case of Emacs users.

reply via email to

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