help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: Emacs 26.1 on Windows is HUGE


From: Björn Lindqvist
Subject: Re: Emacs 26.1 on Windows is HUGE
Date: Tue, 16 Apr 2019 22:57:35 +0200

Den mån 15 apr. 2019 kl 13:42 skrev Phillip Lord <phillip.lord@russet.org.uk>:
> > On addition to that, one thing that makes little for this distribution
> > is to include emacs.exe and emacs-26.1.exe, which are identical.
> >
> > BTW, 26.2 was just released, although the binary pretests on
> >
> > https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-26/
> >
> > have the same size.
> >
> > You can use `strip.exe' (from binutils) to remove the debug information.
> >
> > You can use M-x report-emacs-bug to suggest removing debug info prior to
> > packaging and/or not including redundant executables as emacs-26.1.exe.
>
> Removing the redundant executables would break things for people who
> want to unpack over an MSYS installation.

Perhaps the MSYS users can be taught to run cp emacs.exe
emacs-26.1.exe as a post-installation command? It seems like a vastly
superior alternative to wasting both bandwidth and disk space for the
large majority of Emacs users on Windows who are not interested in
MSYS.

> If you really care about the disk space (100Mb is really stretching
> the definition of "huge" these days), using file system level
> compression would solve this problem, as well as reducing the size
> of other parts of Emacs also.
>
> Happy for there to be a discussion about debug information of
> emacs-devel, though. If it's not needed, it can be removed.

I'm using old hardware with a small SSD which I'm happy with. I don't
want to have to update my hardware to accommodate Emacs growing
requirements.

While the 100mb file doesn't consume more memory, it takes longer to
load than an 8mb executable. Compressing it would increase the load
time further.

I'll happily start a discussion on emacs-devel. I just wanted to first
make sure I'm not resurrecting an old flame war or something along
those lines. Like political reasons for Windows Emacs being packaged
that way. If it is just neglect causing the bad packaging then I can
probably help fix that. I have some experience packaging Linux
applications for Windows.


--
mvh/best regards Björn Lindqvist



reply via email to

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