Re: Bloat in the Emacs Windows package

[Eli Zaretskii]

On April 17, 2019 8:01:56 AM GMT+03:00, "Björn Lindqvist" <address@hidden> 
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.