[Top][All Lists]

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

Re: Emacs 26.1 on Windows is HUGE

From: Eli Zaretskii
Subject: Re: Emacs 26.1 on Windows is HUGE
Date: Wed, 17 Apr 2019 07:13:42 +0300
User-agent: K-9 Mail for Android

On April 17, 2019 6:34:40 AM GMT+03:00, "Óscar Fuentes" <> wrote:
> Eli Zaretskii <> writes:
> >> From: Björn Lindqvist <>
> >> Date: Wed, 17 Apr 2019 00:18:27 +0200
> >> Cc: Óscar Fuentes <>,
> >> 
> >> As someone who don't use MSYS I don't understand the advantage of
> >> duplicating the files?
> >
> > This has nothing to do with MSYS.  It's for when you install the
> next
> > version, emacs.exe gets overwritten, but emacs-26.1.exe stays, and
> you
> > can still invoke it.  IOW, it allows you to have several Emacs
> > versions installed simultaneously.
> >
> > We didn't invent this for Windows, this is how Emacs installs itself
> > on all supported systems.  We just follow that on Windows, to be
> > consistent with all the other systems.
> To be fair, on *nix (where the current build and install system was
> developed) emacs is a symlink to emacs-XX-Y, so there is no disk space
> wasted. On Windows that's not the case.
> Having multiple installed versions makes sense for Emacs developers
> and
> for users who build from sources and don't want to delete the old
> version before testing the new one. But for most users, who install
> packaged binaries, it is not all that important.
> I see little real application for that duplication on Windows and
> hardly
> anybody will care about not having emacs.XX.Y.exe along with
> emacs.exe.
> For many years that was the case and nobody complained AFAIK.
> I don't really care about this duplication on Emacs, though, as it is
> a comparatively minor offender. The lack of usable symlinks on Windows
> makes certain packages to use more than 1 GB of disk space (without
> debug info) when on GNU/Linux use a fraction of that, just because the
> developers of those packages work on *nix and take symlinks for
> granted.

The build procedure creates a link on Windows as well.  If ln.exe used at build 
time supports symlinks, you get a symlink; but in most cases, that will be a 
hard link.  It doesn't really matter, since both avoid wasting disk space 
(actually, a hard link uses even less space than a symlink).

However, I think zip format on Windows doesn't support links.  Or maybe it's a 
problem with the version of zip.exe used to create the binary distribution.  So 
installation from zip ends up with 2 identical files.

You are entitled to your opinion regarding the usefulness of producing 2 names 
for the binary, but that is not a Windows specific problem.  As long as Emacs 
as a project does that, I see no good reasons to deviate from that practice 
only on Windows.

reply via email to

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