Re: Bloat in the Emacs Windows package

[Phillip Lord]

Björn Lindqvist <address@hidden> writes:

> 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



Yes. I have produced these via a script which is simplistic. You can
find it at admin/nt/dist-build/build-dep-zips.py. It is basically the
transitive dependencies of all Emacs dependencies. It's undoubtly to
wide (including python for example as you point out).

This does give Emacs a fairly full msys install. It would be possible to
shrink it do the direct dependencies (i.e. the lib files), but decided
completeness made more sense.


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

Adding emacs.bat would require seperate logic for windows.


>
> 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 simply for me to remove the -g option from the windows build. This
would reduce the overall size of the build, to the values given here:

http://lists.gnu.org/archive/html/help-gnu-emacs/2019-04/msg00115.html

I am happy to do this (for Emacs-27 -- I do not want to change during
major release). But I would like feedback from people who either use or
handle bug reports for Emacs on Windows to let me know whether this
would break things.


> For people with limited disk space, metered internet or old hardware
> the new, bigger Emacs is a nuisance. 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 is also
> aesthetically displeasing -- hackers like minimalism and hate bloat.
>
> 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.

I haven't written one. There is an .exe installer for Emacs-27. I
haven't worked out how to do an MSI yet; if there is a good free package
for doing so, that can be used straight-forwardly within the current
build, I would be happy to add it.

Incidentally, the installer version with all deps is smaller than the
current version with deps, because the compression is better, which
addresses some of your "bandwidth" concerns.

Phil