Re: Bloat in the Emacs Windows package

[Eli Zaretskii <eliz@gnu.org>]

On April 17, 2019 8:01:56 AM GMT+03:00, "Björn Lindqvist" <bjourne@gmail.com> wrote:
> The emacs-26.1-x86_64.zip file is really big. It contains a lot of
> files which I wonder why they are necessary. Some examples
> 
>     python2.7.exe
>     gdbus.exe
>     libgdk_pixbuf-2.0-0.dll
>     include/jasper/
>     include/GL
>     include/gnutls AND include/openssl
>     lib/systemd
>     sqlite3200.dll
>     lib/pkgconfig
>     lib/cmake
>     share/bash-completion
>     share/vala
>     ...

Some people want the binary zip to include all the optional features that Emacs on Windows can support.  This zip includes all of the dependencies for those optional features.  Arguably, some of the auxiliary files, like header files and import libraries, could be omitted, but determining which ones are required is a very non-trivial and time-consuming job, so I can understand why Phillip, who volunteered to produce the binary zips, didn't do that.  This "one cannot fit all" problem is why we also have the bare-minimum zip with only the dependencies that are absolutely required.

> The emacs-26.1-x86_64-no-deps.zip installation is smaller, but still
> double the size of the corresponding 24.5 installation. This seem to
> be because all binaries now include debugging symbols. Some examples
> of the size increases:
> 
>     addpm.exe 577 kB => 2 282 kB
>     ctags.exe 956 kB => 3 245 kB
>     emacs.exe 8 989 kB => 121 740 kB
>     emacs-24.5.exe 8 989 kB => 121 740 kB (emacs-26.1.exe)

Stripping emacs.exe produces a 29MB file for Emacs 26.2.

We could perhaps move the debug info to a separate file and distribute it in a separate zip archive, but whether Phillip can afford that is entirely up to him.  He does that on his own free time; the Emacs project doesn't produce any "official" binaries, on any system.

> The emacs.exe growth is especially annoying because the file is
> copied. This seems like poor packaging to me. Why not have an
> emacs.bat file calling emacs-26.1.exe and immediately save 121M?

What you see in the zip is what the stock Emacs build procedure produces (except that originally the two Emacs executables are hard links to the same file data; but zip format doesn't support hard links, AFAIK).  The reason for that is to allow installation of additional versions on the same filesystem tree.

We don't provide any shell scripts or batch files because the build on Posix systems doesn't.  Once again, it's hard to blame volunteers for using the build products as is, without adding any more work.

> According to the thread on help-gnu-emacs Emacs binaries used to be
> stripped of debugging symbols, but aren't anymore and that is what is
> causing the size increase. I wonder if we can return that? Most
> software ported to Windows, such as MinGW, strips debugging symbols so
> it is customary. For most users they are useless because they don't
> run emacs.exe in gdb.exe.

It is a great help to have debug info when problems are reported that cause crashes and cannot be easily reproduced.  But if Phillip can afford prodicing separate debug info file for Emacs, we could have the cake and eat it, too.    The other programs can be stripped, as far as Emacs is concerned (but they are much smaller, so the savings in disk space will be small).

> On my machine it increases Emacs
> start time by a second (although I don't know if that is caused by the
> debugging symbols or if it is something else). 

It cannot be due to debug info, because that is not read when the program loads.

> It is also
> aesthetically displeasing -- hackers like minimalism and hate bloat.

FWIW, I think you the first one to complain about this.

> And while on the subject of Windows packaging. How come there is no
> MSI installer for Emacs? It shouldn't be to hard to put one together
> and it would make Emacs a little easier to install for newbies.

What tools to use to produce the binary distribution is entirely up to the person who does that.  And of course MSI is not free software.