[Top][All Lists]

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

Re: Suppressing native compilation (short and long term)

From: tomas
Subject: Re: Suppressing native compilation (short and long term)
Date: Wed, 5 Oct 2022 19:59:38 +0200

On Wed, Oct 05, 2022 at 07:47:58PM +0300, Eli Zaretskii wrote:
> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: Eli Zaretskii <eliz@gnu.org>,  spwhitton@spwhitton.name,
> >   rlb@defaultvalue.org,  monnier@iro.umontreal.ca,  david@tethera.net,
> >   emacs-devel@gnu.org,  akrl@sdf.org
> > Date: Wed, 05 Oct 2022 17:02:45 +0200
> > 
> > Po Lu <luangruo@yahoo.com> writes:
> > 
> > > That makes the fans less loud (they are still noticable), but it also
> > > takes twice as long for the fans to subside, as expected.
> > >
> > > Hope this data point ends up meaningful.
> > 
> > Yes.
> > 
> > Software is distributed pre-compiled for a reason -- because people run
> > the software on hardware where compiling the software takes a long time.
> > It's entirely reasonable for people to want to have a fully-built
> > native-compiled Emacs installation on their laptops, without making that
> > Emacs do any further JIT compilation.  (Except where necessary for
> > trampolines, of course.)
> Why would people want to have N files compiled, but not the N+1st
> file?  How are the first N files different from the N+1st?

Perhaps because 1500 <= N <= 2000 (or so) and the N+1st ist just one?
Perhaps because in the "normal case", the N+1st won't even happen?

The idea of a Debian package is to provide a baseline for those
just interested in using that software (with an easy ramp to
upgrade to actually hack at the sources and build a modified

I actually install a few packages from source, those I "personally"
care about (Emacs is among them), But I couldn't possibly do it for
the > 2000 currently installed on my system.

The (Debian) packager's job is to make sure all that stuff works
nicely (and as repeatably as possible) together, and still receive
the necessary security fixes.

Perhaps it would make sense for the Debian Emacs packagers (Rob?)
to state their requirements in some more abstract way and work
from there.

As far as I understand, the wishes are:

 (a) deliver a package with (all? as many as possible? most? .eln
 (b) build Emacs in a way that is idempotent (and doesn't change
  overall system state
 (c) perhaps run tests (possibly, ideally part of b)

Did I forget anything?

> > This has been requested a number of times over several years now, but
> > these requests have been ignored because apparently "people shouldn't
> > want that".
> That's an incorrect and unfair accusation, so please stop.

Attachment: signature.asc
Description: PGP signature

reply via email to

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