Emacs 26.1 on Windows is HUGE

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Emacs 26.1 on Windows is HUGE

BJörn Lindqvist
I thought it was time to update my version of Emacs on Windows. So I
download emacs-26.1-x86_64-no-deps.zip package from
http://ftp.gnu.org/gnu/emacs/windows/emacs-26/. It is a whopping 109
mb and consumes 407 mb of space uncompressed. The emacs.exe file
itself is 121 mb. In comparison the emacs 24.5 installation consumes
160 mb and emacs.exe itself 8 mb.

I posit that there is something wrong with the way Emacs is packaged
for Windows. Perhaps there is a more lightweight distribution?


--
mvh/best regards Björn Lindqvist

Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

Óscar Fuentes
Björn Lindqvist <[hidden email]> writes:

> I thought it was time to update my version of Emacs on Windows. So I
> download emacs-26.1-x86_64-no-deps.zip package from
> http://ftp.gnu.org/gnu/emacs/windows/emacs-26/. It is a whopping 109
> mb and consumes 407 mb of space uncompressed. The emacs.exe file
> itself is 121 mb. In comparison the emacs 24.5 installation consumes
> 160 mb and emacs.exe itself 8 mb.
>
> I posit that there is something wrong with the way Emacs is packaged
> for Windows. Perhaps there is a more lightweight distribution?

Most likely the executables include debug information. It uses disk
space but no RAM.

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.

Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

Phillip Lord-3
Óscar Fuentes <[hidden email]> writes:

> Björn Lindqvist <[hidden email]> writes:
>
>> I thought it was time to update my version of Emacs on Windows. So I
>> download emacs-26.1-x86_64-no-deps.zip package from
>> http://ftp.gnu.org/gnu/emacs/windows/emacs-26/. It is a whopping 109
>> mb and consumes 407 mb of space uncompressed. The emacs.exe file
>> itself is 121 mb. In comparison the emacs 24.5 installation consumes
>> 160 mb and emacs.exe itself 8 mb.
>>
>> I posit that there is something wrong with the way Emacs is packaged
>> for Windows. Perhaps there is a more lightweight distribution?
>
> Most likely the executables include debug information. It uses disk
> space but no RAM.

They do. In addition, between 24 and 25 there was a change of build system.

> 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. 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.

Phil

Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

Óscar Fuentes
Phillip Lord <[hidden email]> writes:

> Removing the redundant executables would break things for people who
> want to unpack over an MSYS installation.

"People who want to install multiple Emacs versions on the same
directory root", not necessarily those who use MSYS, correct?


Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

Phillip Lord-3
Óscar Fuentes <[hidden email]> writes:

> Phillip Lord <[hidden email]> writes:
>
>> Removing the redundant executables would break things for people who
>> want to unpack over an MSYS installation.
>
> "People who want to install multiple Emacs versions on the same
> directory root", not necessarily those who use MSYS, correct?

Yes, this generalization is correct. AFAICT, though, only people with a
lot of other, non emacs, files are going to benefit from doing this as
multiple versions of emacs with one root take up the same size as
multiple versions with several roots. This is why msys was in my head.

I have checked now. Building Emacs with no debug reduces the size of the
executable from 120M to about 30M. The overall impact on install size is
as follows. For released versions we have:


170M 24
359M 25
742M 26-deps
412M 26-no-deps
109M emacs-26.2-x86_64-no-deps.zip
211M emacs-26.2-x86_64.zip

So, the size with no dependences has gone up a lot (this data is from
files on GNU/Linux).

For direct comparision with and without debugging we have without:

307M    deps
148M    emacs-26.2-i686.zip
50M     emacs-26.2-i686-no-deps.zip
150M    emacs-26.2-x86_64.zip
51M     emacs-26.2-x86_64-no-deps.zip
99M     no-deps
803M    total


and with:

$ du -shc *
401M    deps
208M    emacs-26.2-x86_64.zip
109M    emacs-26.2-x86_64-no-deps.zip
193M    nodeps
909M    total


So, for the no-deps version, we have a 50% reduction in the zip file
which equates to a 100% reduction on disk (assuming no file system
compression). Obviously for the with deps version, the proportions are
much smaller, but the actual size change the same.

Phil

Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

BJörn Lindqvist
In reply to this post by Óscar Fuentes
> Most likely the executables include debug information. It uses disk
> space but no RAM.
>
> 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.

I tried that. I downloaded the strip.exe fom

https://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/binutils-2.28/

But when running it on the binary:

    > C:\code\langs\MingGW\bin\strip.exe -s emacs.exe
    C:\code\langs\MingGW\bin\strip.exe:emacs.exe: File format not recognized


--
mvh/best regards Björn Lindqvist

Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

Óscar Fuentes
Björn Lindqvist <[hidden email]> writes:

>> Most likely the executables include debug information. It uses disk
>> space but no RAM.
>>
>> 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.
>
> I tried that. I downloaded the strip.exe fom
>
> https://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/binutils-2.28/
>
> But when running it on the binary:
>
>     > C:\code\langs\MingGW\bin\strip.exe -s emacs.exe
>     C:\code\langs\MingGW\bin\strip.exe:emacs.exe: File format not recognized

You have Emacs x86_64 and that "strip.exe" executable is for i686. That
means that you have a 64 bits Emacs Windows executable but the strip.exe
executable was configured for working on 32 bits executables.

Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

BJörn Lindqvist
In reply to this post by Phillip Lord-3
Den mån 15 apr. 2019 kl 13:42 skrev Phillip Lord <[hidden email]>:

> > 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 | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

Phillip Lord-3
Björn Lindqvist <[hidden email]> writes:

>> 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.

Maybe. We are talking about 100Mb, which currently costs a fraction of
the smallest unit of most currencies; so I am struggling with
"vastly". I would guess that it is the minority of users who care about
this; they can, of course, rm emacs-26.1.exe with no harmful effects.

>
>> 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.

Likewise here I am a bit surprised. You can notice the difference
between 100mb vs 8mb on a SSD drive?

I use compression on the build machine for Emacs for Windows and it does
have an impact on the overall size, although that machine has lots of
copies of the same files.

> 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.

I genuinely do not know why it is that way, although it was probably me
that made it so. I would guess because Eli finds it easier to get better
bug reports. Maybe it's just a mess up on my behalf. That's why I
suggest you ask.

Phil

Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

BJörn Lindqvist
Den tis 16 apr. 2019 kl 23:19 skrev Phillip Lord <[hidden email]>:

> >> 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.
>
> Maybe. We are talking about 100Mb, which currently costs a fraction of
> the smallest unit of most currencies; so I am struggling with
> "vastly". I would guess that it is the minority of users who care about
> this; they can, of course, rm emacs-26.1.exe with no harmful effects.

Yes, if they are power users like you and me who knows that removing
that file is safe. I think for most users one file is sufficient
because it reduces bandwidth usage (I'm on a metered internet
connection so larger files are more expensive) and disk space.

As someone who don't use MSYS I don't understand the advantage of
duplicating the files? You mentioned unzipping Emacs over an MSYS
installation, but that seems a little odd. Usually on Windows you
don't install software that way. But maybe for your use case you can
use the larger emacs-26.1-x86_64.zip file? It includes a lot of
dependencies like Python2.7, Sqlite 3.20, and OpenGL headers which I
don't understand what they are doing.

> > 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.
>
> Likewise here I am a bit surprised. You can notice the difference
> between 100mb vs 8mb on a SSD drive?

For sure. :) But I like to waste time optimizing software so perhaps
I'm more sensitive than most. Hot start of Emacs 24.5.1 takes almost
exactly 7 seconds and of 26.1 8 seconds. I do not know how much of the
slowdown is caused by the larger executable, but I bet at least some
of it is (I will have to check after I have installed the right
version of MinGW and the right version of strip.exe). If Windows is
doing stuff in the background (like disk indexing or whatever its
services are doing) the load times increases further.

> I genuinely do not know why it is that way, although it was probably me
> that made it so. I would guess because Eli finds it easier to get better
> bug reports. Maybe it's just a mess up on my behalf. That's why I
> suggest you ask.

Will do!


--
mvh/best regards Björn Lindqvist

Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

Eli Zaretskii
> From: Björn Lindqvist <[hidden email]>
> Date: Wed, 17 Apr 2019 00:18:27 +0200
> Cc: Óscar Fuentes <[hidden email]>, [hidden email]
>
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

Óscar Fuentes
Eli Zaretskii <[hidden email]> writes:

>> From: Björn Lindqvist <[hidden email]>
>> Date: Wed, 17 Apr 2019 00:18:27 +0200
>> Cc: Óscar Fuentes <[hidden email]>, [hidden email]
>>
>> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

BJörn Lindqvist
In reply to this post by Óscar Fuentes
Den tis 16 apr. 2019 kl 22:54 skrev Óscar Fuentes <[hidden email]>:

>
> Björn Lindqvist <[hidden email]> writes:
>
> >> Most likely the executables include debug information. It uses disk
> >> space but no RAM.
> >>
> >> 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.
> >
> > I tried that. I downloaded the strip.exe fom
> >
> > https://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/binutils-2.28/
> >
> > But when running it on the binary:
> >
> >     > C:\code\langs\MingGW\bin\strip.exe -s emacs.exe
> >     C:\code\langs\MingGW\bin\strip.exe:emacs.exe: File format not recognized
>
> You have Emacs x86_64 and that "strip.exe" executable is for i686. That
> means that you have a 64 bits Emacs Windows executable but the strip.exe
> executable was configured for working on 32 bits executables.

I downloaded the 64bit MinGW (from here
https://sourceforge.net/projects/mingw-w64/)
and that strip.exe doesn't work either:

    >C:\code\langs\MingGW-64\mingw32\bin\strip.exe emacs.exe
    C:\code\langs\MingGW-64\mingw32\bin\strip.exe:emacs.exe: File
format not recognized


--
mvh/best regards Björn Lindqvist

Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

Eli Zaretskii
In reply to this post by Óscar Fuentes
On April 17, 2019 6:34:40 AM GMT+03:00, "Óscar Fuentes" <[hidden email]> wrote:

> Eli Zaretskii <[hidden email]> writes:
>
> >> From: Björn Lindqvist <[hidden email]>
> >> Date: Wed, 17 Apr 2019 00:18:27 +0200
> >> Cc: Óscar Fuentes <[hidden email]>, [hidden email]
> >>
> >> 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 | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

Óscar Fuentes
In reply to this post by BJörn Lindqvist
Björn Lindqvist <[hidden email]> writes:

>> >     > C:\code\langs\MingGW\bin\strip.exe -s emacs.exe
>> >     C:\code\langs\MingGW\bin\strip.exe:emacs.exe: File format not recognized
>>
>> You have Emacs x86_64 and that "strip.exe" executable is for i686. That
>> means that you have a 64 bits Emacs Windows executable but the strip.exe
>> executable was configured for working on 32 bits executables.
>
> I downloaded the 64bit MinGW (from here
> https://sourceforge.net/projects/mingw-w64/)
> and that strip.exe doesn't work either:
>
>     >C:\code\langs\MingGW-64\mingw32\bin\strip.exe emacs.exe
>     C:\code\langs\MingGW-64\mingw32\bin\strip.exe:emacs.exe: File
> format not recognized

You downloaded the 32bit MinGW-w64 toolset, as hinted by the "\mingw32\"
part on the path to strip.exe in your command line.

Despite its name, MinGW-w64 distributes both 32bit and 64bit toolsets.

Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

Phillip Lord-3
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> writes:

>> From: Björn Lindqvist <[hidden email]>
>> Date: Wed, 17 Apr 2019 00:18:27 +0200
>> Cc: Óscar Fuentes <[hidden email]>, [hidden email]
>>
>> 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.


Yes, if you install them in the same location. But if you do the
suggested thing of unpacking them with "extract" from the file explorer
menu, each will get their own directory, so you will have
emacs-26.1/bin/emacs.exe and emacs-26.2/bin/emacs.exe.

How many people unpack one Emacs version over another? There isn't any
real advantage to doing so, unless you want to share files between the
two versions.

Phil

Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

Eli Zaretskii
In reply to this post by Óscar Fuentes
> From: Óscar Fuentes <[hidden email]>
> Date: Wed, 17 Apr 2019 17:25:31 +0200
> Cc: [hidden email]
>
> >     >C:\code\langs\MingGW-64\mingw32\bin\strip.exe emacs.exe
> >     C:\code\langs\MingGW-64\mingw32\bin\strip.exe:emacs.exe: File
> > format not recognized
>
> You downloaded the 32bit MinGW-w64 toolset, as hinted by the "\mingw32\"
> part on the path to strip.exe in your command line.

A nit: that doesn't necessarily mean anything, because a 32-bit build
of 'strip' could well support 64-bit PE executables.  It all depends
on how it was configured.  To know whether it does, say "strip --help"
and look at the list of supported targets at the end.  My 32-bit
binary says:

  strip: supported targets: pe-i386 pei-i386 elf32-i386 elf32-iamcu elf32-little elf32-big pe-x86-64 pei-x86-64 pe-bigobj-x86-64 elf64-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big plugin srec symbolsrec verilog tekhex binary ihex

See that pe-x86-64 stuff there?

Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

Eli Zaretskii
In reply to this post by Phillip Lord-3
> From: [hidden email] (Phillip Lord)
> Cc: [hidden email]
> Date: Wed, 17 Apr 2019 16:28:54 +0100
>
> > 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.
>
> Yes, if you install them in the same location. But if you do the
> suggested thing of unpacking them with "extract" from the file explorer
> menu, each will get their own directory, so you will have
> emacs-26.1/bin/emacs.exe and emacs-26.2/bin/emacs.exe.

The Explorer lets you control the root directory where you extract the
files.  What you say above is only the default, if the user doesn't
change what Explorer suggests.

> How many people unpack one Emacs version over another? There isn't any
> real advantage to doing so, unless you want to share files between the
> two versions.

If you want to make the second binary optional, or remove it tell
people who want to keep the old version what do, it's entirely up to
you.  Since you are producing the binaries, you get to decide on these
details (and also to handle the complaints ;-).

I wrote the above to explain that this arrangement is not something
invented for Windows, it's how Emacs installs itself on all
platforms.

Reply | Threaded
Open this post in threaded view
|

Re: Emacs 26.1 on Windows is HUGE

Tomas Nordin-2
In reply to this post by BJörn Lindqvist
Björn Lindqvist <[hidden email]> writes:

> As someone who don't use MSYS I don't understand the advantage of
> duplicating the files? You mentioned unzipping Emacs over an MSYS
> installation, but that seems a little odd. Usually on Windows you
> don't install software that way. But maybe for your use case you can
> use the larger emacs-26.1-x86_64.zip file? It includes a lot of
> dependencies like Python2.7, Sqlite 3.20, and OpenGL headers which I

Since it is mentioned, what is the possible depence on Python for the
emacs installation?

> don't understand what they are doing.
>
>> > 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.

Happy Easter
--
Tomas