Emacs binaries for Windows

Emacs binaries for Windows

[Arash Esbati]

Hi all,

I know this topic has been discussed in past and my apologies in advance
if I'm beating the dead horse again and a longish message.  I'm raising
this question after seeing some queries again about availability of
Emacs on Windows (possibly incl. all necessary libraries (DLLs)).

While building Emacs on Windows with Msys2/MinGW-w64 is quite straight
forward, the main issue is providing the sources of the libraries when
DLLs should be provided as well.  I wrote a simple script to determine
the dependencies of the required packages mentioned here:

    http://git.savannah.gnu.org/cgit/emacs.git/tree/nt/INSTALL.W64#n60

It downloads the original sources mentioned in every PKGBUILD file and
includes patches from here:

    https://github.com/Alexpux/MINGW-packages

Resulting in:

    -> du -hc *.tar.gz
    780K    mingw-w64-bzip2-1.0.6-5.src.tar.gz
    36M     mingw-w64-cairo-1.15.2-2.src.tar.gz
    400K    mingw-w64-expat-2.1.1-1.src.tar.gz
    1.6M    mingw-w64-fontconfig-2.12.0-2.src.tar.gz
    1.8M    mingw-w64-freetype-2.6.5-1.src.tar.gz
    95M     mingw-w64-gcc-6.1.0-2.src.tar.gz
    2.6M    mingw-w64-gdk-pixbuf2-2.35.1-1.src.tar.gz
    19M     mingw-w64-gettext-0.19.7-1.src.tar.gz
    628K    mingw-w64-giflib-5.1.4-1.src.tar.gz
    7.2M    mingw-w64-glib2-2.48.1-1.src.tar.gz
    1.9M    mingw-w64-gmp-6.1.1-1.src.tar.gz
    6.6M    mingw-w64-gnutls-3.5.2-1.src.tar.gz
    3.5M    mingw-w64-graphite2-1.3.8-4.src.tar.gz
    1.3M    mingw-w64-harfbuzz-1.2.7-2.src.tar.gz
    1.4M    mingw-w64-jasper-1.900.1-4.src.tar.gz
    468K    mingw-w64-libcroco-0.6.11-1.src.tar.gz
    920K    mingw-w64-libffi-3.2.1-4.src.tar.gz
    4.3M    mingw-w64-libiconv-1.14-5.src.tar.gz
    3.4M    mingw-w64-libidn-1.32-3.src.tar.gz
    1.5M    mingw-w64-libjpeg-turbo-1.4.2-2.src.tar.gz
    936K    mingw-w64-libpng-1.6.21-1.src.tar.gz
    552K    mingw-w64-librsvg-2.40.16-1.src.tar.gz
    220K    mingw-w64-libsystre-1.0.1-2.src.tar.gz
    1.8M    mingw-w64-libtasn1-4.8-1.src.tar.gz
    2.1M    mingw-w64-libtiff-4.0.6-1.src.tar.gz
    396K    mingw-w64-libtre-git-r122.c2f5d13-4.src.tar.gz
    5.2M    mingw-w64-libxml2-2.9.4-1.src.tar.gz
    584K    mingw-w64-lzo2-2.09-2.src.tar.gz
    1.8M    mingw-w64-nettle-3.2-1.src.tar.gz
    1012K   mingw-w64-p11-kit-0.23.2-2.src.tar.gz
    1.1M    mingw-w64-pango-1.40.1-1.src.tar.gz
    1.5M    mingw-w64-pcre-8.38-2.src.tar.gz
    724K    mingw-w64-pixman-0.34.0-2.src.tar.gz
    92K     mingw-w64-wineditline-2.101-4.src.tar.gz
    30M     mingw-w64-winpthreads-git-5.0.0.4670.00cda6f-1.src.tar.gz
    144K    mingw-w64-xpm-nox-4.2.0-4.src.tar.gz
    1.4M    mingw-w64-xz-5.2.2-1.src.tar.gz
    1.5M    mingw-w64-zlib-1.2.8-9.src.tar.gz
    239M    total

Is this a way to go for Emacs?

Personally, I recommend another approach where only Msys2 package
directories (which Emacs was built against) are provided and downloading
and packaging can be done when a developer/user wants to have it, e.g.:

    cd mingw-w64-bzip2
    makepkg-mingw --allsource -sLf

This is actually what my script does.  Collecting all directories for
the packages above gives:

    -> du -h emacs-25.1-rc1-libs.tar.xz
    464K    emacs-25.1-rc1-libs.tar.xz

Does this approach comply with GPL?

Best, Arash

Re: Emacs binaries for Windows

[Eli Zaretskii]

> From: Arash Esbati <arash.esbati@gmail.com>
> Date: Fri, 19 Aug 2016 09:45:41 +0200
> 
> While building Emacs on Windows with Msys2/MinGW-w64 is quite straight
> forward, the main issue is providing the sources of the libraries when
> DLLs should be provided as well.  I wrote a simple script to determine
> the dependencies of the required packages mentioned here:
> 
>     http://git.savannah.gnu.org/cgit/emacs.git/tree/nt/INSTALL.W64#n60
> 
> It downloads the original sources mentioned in every PKGBUILD file and
> includes patches from here:
> 
>     https://github.com/Alexpux/MINGW-packages
> 
> Resulting in:
> 
>     -> du -hc *.tar.gz
>     780K    mingw-w64-bzip2-1.0.6-5.src.tar.gz
>     36M     mingw-w64-cairo-1.15.2-2.src.tar.gz
>     400K    mingw-w64-expat-2.1.1-1.src.tar.gz
>     1.6M    mingw-w64-fontconfig-2.12.0-2.src.tar.gz
>     1.8M    mingw-w64-freetype-2.6.5-1.src.tar.gz
>     95M     mingw-w64-gcc-6.1.0-2.src.tar.gz
>     2.6M    mingw-w64-gdk-pixbuf2-2.35.1-1.src.tar.gz
>     19M     mingw-w64-gettext-0.19.7-1.src.tar.gz
>     628K    mingw-w64-giflib-5.1.4-1.src.tar.gz
>     7.2M    mingw-w64-glib2-2.48.1-1.src.tar.gz
>     1.9M    mingw-w64-gmp-6.1.1-1.src.tar.gz
>     6.6M    mingw-w64-gnutls-3.5.2-1.src.tar.gz
>     3.5M    mingw-w64-graphite2-1.3.8-4.src.tar.gz
>     1.3M    mingw-w64-harfbuzz-1.2.7-2.src.tar.gz
>     1.4M    mingw-w64-jasper-1.900.1-4.src.tar.gz
>     468K    mingw-w64-libcroco-0.6.11-1.src.tar.gz
>     920K    mingw-w64-libffi-3.2.1-4.src.tar.gz
>     4.3M    mingw-w64-libiconv-1.14-5.src.tar.gz
>     3.4M    mingw-w64-libidn-1.32-3.src.tar.gz
>     1.5M    mingw-w64-libjpeg-turbo-1.4.2-2.src.tar.gz
>     936K    mingw-w64-libpng-1.6.21-1.src.tar.gz
>     552K    mingw-w64-librsvg-2.40.16-1.src.tar.gz
>     220K    mingw-w64-libsystre-1.0.1-2.src.tar.gz
>     1.8M    mingw-w64-libtasn1-4.8-1.src.tar.gz
>     2.1M    mingw-w64-libtiff-4.0.6-1.src.tar.gz
>     396K    mingw-w64-libtre-git-r122.c2f5d13-4.src.tar.gz
>     5.2M    mingw-w64-libxml2-2.9.4-1.src.tar.gz
>     584K    mingw-w64-lzo2-2.09-2.src.tar.gz
>     1.8M    mingw-w64-nettle-3.2-1.src.tar.gz
>     1012K   mingw-w64-p11-kit-0.23.2-2.src.tar.gz
>     1.1M    mingw-w64-pango-1.40.1-1.src.tar.gz
>     1.5M    mingw-w64-pcre-8.38-2.src.tar.gz
>     724K    mingw-w64-pixman-0.34.0-2.src.tar.gz
>     92K     mingw-w64-wineditline-2.101-4.src.tar.gz
>     30M     mingw-w64-winpthreads-git-5.0.0.4670.00cda6f-1.src.tar.gz
>     144K    mingw-w64-xpm-nox-4.2.0-4.src.tar.gz
>     1.4M    mingw-w64-xz-5.2.2-1.src.tar.gz
>     1.5M    mingw-w64-zlib-1.2.8-9.src.tar.gz
>     239M    total
> 
> Is this a way to go for Emacs?
> 
> Personally, I recommend another approach where only Msys2 package
> directories (which Emacs was built against) are provided and downloading
> and packaging can be done when a developer/user wants to have it, e.g.:
> 
>     cd mingw-w64-bzip2
>     makepkg-mingw --allsource -sLf
> 
> This is actually what my script does.  Collecting all directories for
> the packages above gives:
> 
>     -> du -h emacs-25.1-rc1-libs.tar.xz
>     464K    emacs-25.1-rc1-libs.tar.xz
> 
> Does this approach comply with GPL?

It's not clear to me what exactly is the question(s) you are asking.
The upshot of the GPL requirements is that the sources -- the same
sources that were used for building the binaries, with any changes
made for that purpose -- should be available for download from the
same site as the binaries.  If the above fulfills this requirement, it
complies with the GPL.  (I cannot tell if this is so because I don't
know what makepkg-mingw does, or what those command-line switches
mean.)

Thanks.

Re: Emacs binaries for Windows

[Phillip Lord]

Arash Esbati <arash.esbati@gmail.com> writes:
> I know this topic has been discussed in past and my apologies in advance
> if I'm beating the dead horse again and a longish message.

It's not a dead horse at all. It's an issue which, to my mind, needs
solving.

> I'm raising this question after seeing some queries again about
> availability of Emacs on Windows (possibly incl. all necessary
> libraries (DLLs)).
>
> While building Emacs on Windows with Msys2/MinGW-w64 is quite straight
> forward, the main issue is providing the sources of the libraries when
> DLLs should be provided as well.  I wrote a simple script to determine
> the dependencies of the required packages mentioned here:
>
>     http://git.savannah.gnu.org/cgit/emacs.git/tree/nt/INSTALL.W64#n60


I'd be interested to see this script.


> It downloads the original sources mentioned in every PKGBUILD file and
> includes patches from here:
>
>     https://github.com/Alexpux/MINGW-packages
>
> Is this a way to go for Emacs?


> Personally, I recommend another approach where only Msys2 package
> directories (which Emacs was built against) are provided and downloading
> and packaging can be done when a developer/user wants to have it, e.g.:
>
>     cd mingw-w64-bzip2
>     makepkg-mingw --allsource -sLf
>
> This is actually what my script does.  Collecting all directories for
> the packages above gives:
>
>     -> du -h emacs-25.1-rc1-libs.tar.xz
>     464K    emacs-25.1-rc1-libs.tar.xz
>
> Does this approach comply with GPL?


I don't know enough about msys2 to understand the difference in your
approaches, but AFAICT, -libs.tar.xv contains all the source, so that
you could build the libraries, then it does, yes.

At the moment, Emacs ships with a single binary (libnox4) otherwise it
looks terrible. But, I think that the basic windows download cannot do
an HTTP call and display the results is unfortunate.

Current builds are for 32 bit as well as 64 bit. Can that be replicated
also?

Phil

Re: Emacs binaries for Windows

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arash Esbati <arash.esbati@gmail.com>
>> Date: Fri, 19 Aug 2016 09:45:41 +0200
>> 
>> While building Emacs on Windows with Msys2/MinGW-w64 is quite straight
>> forward, the main issue is providing the sources of the libraries when
>> DLLs should be provided as well.  I wrote a simple script to determine
>> the dependencies of the required packages mentioned here:
>> 
>>     http://git.savannah.gnu.org/cgit/emacs.git/tree/nt/INSTALL.W64#n60
>> 
>> It downloads the original sources mentioned in every PKGBUILD file and
>> includes patches from here:
>> 
>>     https://github.com/Alexpux/MINGW-packages
>> 
>> Resulting in:
>> [...]
>>     400K    mingw-w64-expat-2.1.1-1.src.tar.gz
>> [...]
>> 
>> Is this a way to go for Emacs?
>
> It's not clear to me what exactly is the question(s) you are asking.
> The upshot of the GPL requirements is that the sources -- the same
> sources that were used for building the binaries, with any changes
> made for that purpose -- should be available for download from the
> same site as the binaries.  If the above fulfills this requirement, it
> complies with the GPL.  (I cannot tell if this is so because I don't
> know what makepkg-mingw does, or what those command-line switches
> mean.)

Thanks for your response.  I try to give an example: Currently, Msys2
delivers a package named

    mingw-w64-x86_64-expat-2.1.1-1-any.pkg.tar.xz

containing `libexpat-1.dll'.  If you clon the repository from

    https://github.com/Alexpux/MINGW-packages.git

and cd to `./MINGW-packages/mingw-w64-expat', the command

    makepkg-mingw --allsource -sLf

downloads the original sources from

    https://downloads.sourceforge.net/expat/expat-2.1.1.tar.bz2

and makes an archive

    mingw-w64-expat-2.1.1-1.src.tar.gz

containing the archive from sourceforge and a Msys2 specific patch
called `001-fix-extension.patch' (plus PKGBUILD & .SRCINFO files).

My first question is: With the provision made above, can the file
`libexpat-1.dll' be distributed along with an Emacs binary, which is
also built against this DLL file? (I will come back with a second
question later).

Best, Arash

Re: Emacs binaries for Windows

[Arash Esbati]

[-- Attachment #1: Type: text/plain, Size: 3845 bytes --]

phillip.lord@russet.org.uk (Phillip Lord) writes:

> Arash Esbati <arash.esbati@gmail.com> writes:
>> I know this topic has been discussed in past and my apologies in advance
>> if I'm beating the dead horse again and a longish message.
>
> It's not a dead horse at all. It's an issue which, to my mind, needs
> solving.

Thanks for the thumbs-up Phil, glad I'm not the only person not happy
with the current state :-)

>> I wrote a simple script to determine the dependencies of the required
>> packages mentioned here:
>>
>>     http://git.savannah.gnu.org/cgit/emacs.git/tree/nt/INSTALL.W64#n60
>
>
> I'd be interested to see this script.

It is really a brain-dead one.  I started with this one to find out the
dependencies of the relevant package:

--8<---------------cut here---------------start------------->8---
#! /usr/bin/bash

# Run this script only in a msys2 shell and not in mingw64:
if [[ $MSYSTEM != "MSYS" ]] ; then
    echo "Run this script in a MSYS-shell -- I stop now!"
    exit 1
fi

# This list derives from the features we want Emacs to compile with.
PKG_REQ="mingw-w64-x86_64-giflib
mingw-w64-x86_64-gnutls
mingw-w64-x86_64-libjpeg-turbo
mingw-w64-x86_64-libpng
mingw-w64-x86_64-librsvg
mingw-w64-x86_64-libtiff
mingw-w64-x86_64-libxml2
mingw-w64-x86_64-xpm-nox"

# tmp file to store the dependencies:
if [ -f "./tmp-pkg-list" ] ; then
    rm ./tmp-pkg-list
fi

touch ./tmp-pkg-list

# Get a list of all dependencies needed for packages mentioned above.
# Run `pactree -lu' for each elment of $PKG_REQ
for x in $PKG_REQ ; do
    pactree -lu $x >> tmp-pkg-list
done

# Sort und uniq the list
cat tmp-pkg-list | sort -u -o tmp-pkg-list
cat tmp-pkg-list | sed 's/x86_64-//' > final-pkg-list
--8<---------------cut here---------------end--------------->8---

Then I found out that some package names differ from the name of
original directory on Github, e.g. `mingw-w64-x86_64-gcc-libs' is built
within the directory `mingw-w64-gcc'.  Long story short, if you clone

    https://github.com/Alexpux/MINGW-packages.git

and run

--8<---------------cut here---------------start------------->8---
#! /usr/bin/bash

PKGS="mingw-w64-bzip2
mingw-w64-cairo
mingw-w64-expat
mingw-w64-fontconfig
mingw-w64-freetype
mingw-w64-gdk-pixbuf2
mingw-w64-gcc
mingw-w64-gettext
mingw-w64-giflib
mingw-w64-glib2
mingw-w64-gmp
mingw-w64-gnutls
mingw-w64-graphite2
mingw-w64-harfbuzz
mingw-w64-jasper
mingw-w64-libcroco
mingw-w64-libffi
mingw-w64-libiconv
mingw-w64-libidn
mingw-w64-libjpeg-turbo
mingw-w64-libpng
mingw-w64-librsvg
mingw-w64-libsystre
mingw-w64-libtasn1
mingw-w64-libtiff
mingw-w64-libtre-git
mingw-w64-libxml2
mingw-w64-lzo2
mingw-w64-nettle
mingw-w64-p11-kit
mingw-w64-pango
mingw-w64-pcre
mingw-w64-pixman
mingw-w64-wineditline
mingw-w64-winpthreads-git
mingw-w64-xpm-nox
mingw-w64-xz
mingw-w64-zlib"

for pkg in $PKGS
do
    pushd ./MINGW-packages/$pkg
    makepkg-mingw --allsource --skipinteg -sLf && \
	mv $pkg-*.tar.gz ../../
    popd
done
--8<---------------cut here---------------end--------------->8---

you have all the sources and patches (239M total) ready.

>> This is actually what my script does.  Collecting all directories for
>> the packages above gives:
>>
>>     -> du -h emacs-25.1-rc1-libs.tar.xz
>>     464K    emacs-25.1-rc1-libs.tar.xz
>>
>> Does this approach comply with GPL?
>
> I don't know enough about msys2 to understand the difference in your
> approaches, but AFAICT, -libs.tar.xv contains all the source, so that
> you could build the libraries, then it does, yes.

No, "all the sources" are in the 239M package.  You could build the
libraries with those files.  My second thought was only to provide the
relevant Msys2/MinGW directives (PKGBUILD files) and patch files, all in
one archive which I called `emacs-25.1-rc1-libs.tar.xz'.  As an
example, I am attaching such a file for `expat'.


[-- Attachment #2: mingw-w64-expat.tar.xz --]
[-- Type: application/octet-stream, Size: 1136 bytes --]

[-- Attachment #3: Type: text/plain, Size: 507 bytes --]


> At the moment, Emacs ships with a single binary (libnox4) otherwise it
> looks terrible. But, I think that the basic windows download cannot do
> an HTTP call and display the results is unfortunate.
>
> Current builds are for 32 bit as well as 64 bit. Can that be replicated
> also?

The way I get it both arch's are built from the same directives
(PKGBUILD files).  Have a look at this page, section `Building
packages':

    https://sourceforge.net/p/msys2/wiki/Contributing%20to%20MSYS2/

Best, Arash

Re: Emacs binaries for Windows

[Eli Zaretskii]

> From: Arash Esbati <arash.esbati@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Fri, 19 Aug 2016 18:33:06 +0200
> 
> Thanks for your response.  I try to give an example: Currently, Msys2
> delivers a package named
> 
>     mingw-w64-x86_64-expat-2.1.1-1-any.pkg.tar.xz
> 
> containing `libexpat-1.dll'.  If you clon the repository from
> 
>     https://github.com/Alexpux/MINGW-packages.git
> 
> and cd to `./MINGW-packages/mingw-w64-expat', the command
> 
>     makepkg-mingw --allsource -sLf
> 
> downloads the original sources from
> 
>     https://downloads.sourceforge.net/expat/expat-2.1.1.tar.bz2
> 
> and makes an archive
> 
>     mingw-w64-expat-2.1.1-1.src.tar.gz
> 
> containing the archive from sourceforge and a Msys2 specific patch
> called `001-fix-extension.patch' (plus PKGBUILD & .SRCINFO files).
> 
> My first question is: With the provision made above, can the file
> `libexpat-1.dll' be distributed along with an Emacs binary, which is
> also built against this DLL file? (I will come back with a second
> question later).

IIUC, no.  The sources are really on another server, so they could
remove them, and your script will simply fail.  The GPL requires that
the binaries and the sources be either both available or both absent.

Once again, the only practical way of complying with GPL is to provide
the source archive from the same server as the binaries.  (The GPL
doesn't request that literally, but I know of no other scheme that
really works.)

Re: Emacs binaries for Windows

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

[snip]

Just in case someone is tempted to jump to conclusions based on this
sub-thread, I'll mention that the MSYS2 project hosts and distributes
the actual sources used for building the binary packages.

Re: Emacs binaries for Windows

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arash Esbati <arash.esbati@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 19 Aug 2016 18:33:06 +0200
>> 
>> Thanks for your response.  I try to give an example: Currently, Msys2
>> delivers a package named
>> 
>>     mingw-w64-x86_64-expat-2.1.1-1-any.pkg.tar.xz
>> 
>> containing `libexpat-1.dll'.  If you clon the repository from
>> 
>>     https://github.com/Alexpux/MINGW-packages.git
>> 
>> and cd to `./MINGW-packages/mingw-w64-expat', the command
>> 
>>     makepkg-mingw --allsource -sLf
>> 
>> downloads the original sources from
>> 
>>     https://downloads.sourceforge.net/expat/expat-2.1.1.tar.bz2
>> 
>> and makes an archive
>> 
>>     mingw-w64-expat-2.1.1-1.src.tar.gz
>> 
>> containing the archive from sourceforge and a Msys2 specific patch
>> called `001-fix-extension.patch' (plus PKGBUILD & .SRCINFO files).
>> 
>> My first question is: With the provision made above, can the file
>> `libexpat-1.dll' be distributed along with an Emacs binary, which is
>> also built against this DLL file? (I will come back with a second
>> question later).
>
> IIUC, no.  The sources are really on another server, so they could
> remove them, and your script will simply fail.  The GPL requires that
> the binaries and the sources be either both available or both absent.
>
> Once again, the only practical way of complying with GPL is to provide
> the source archive from the same server as the binaries.  (The GPL
> doesn't request that literally, but I know of no other scheme that
> really works.)

I see your point, and I'm seeking for a way to store library sources
next to Emacs binaries on the same server.  I think we already have a
solution: the library sources can be packaged the way I have described;
if Phil agrees to go this route as well, he could package the sources
and upload them with the next RC which can be distributed with the
necessary DLLs.

Best, Arash

Re: Emacs binaries for Windows

[Eli Zaretskii]

> From: Arash Esbati <arash.esbati@gmail.com>
> Cc: emacs-devel@gnu.org, phillip.lord@russet.org.uk
> Date: Sat, 20 Aug 2016 17:49:45 +0200
> 
> > Once again, the only practical way of complying with GPL is to provide
> > the source archive from the same server as the binaries.  (The GPL
> > doesn't request that literally, but I know of no other scheme that
> > really works.)
> 
> I see your point, and I'm seeking for a way to store library sources
> next to Emacs binaries on the same server.  I think we already have a
> solution: the library sources can be packaged the way I have described;
> if Phil agrees to go this route as well, he could package the sources
> and upload them with the next RC which can be distributed with the
> necessary DLLs.

Thanks.

FWIW, I think it's better to have the DLLs and their sources available
in separate archives, not in a single large one, because some users
may wish to install only part of the libraries.  But that's me.

Re: Emacs binaries for Windows

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arash Esbati <arash.esbati@gmail.com>
>> Cc: emacs-devel@gnu.org, phillip.lord@russet.org.uk
>> Date: Sat, 20 Aug 2016 17:49:45 +0200
>> 
>> > Once again, the only practical way of complying with GPL is to provide
>> > the source archive from the same server as the binaries.  (The GPL
>> > doesn't request that literally, but I know of no other scheme that
>> > really works.)
>> 
>> I see your point, and I'm seeking for a way to store library sources
>> next to Emacs binaries on the same server.  I think we already have a
>> solution: the library sources can be packaged the way I have described;
>> if Phil agrees to go this route as well, he could package the sources
>> and upload them with the next RC which can be distributed with the
>> necessary DLLs.
>
> Thanks.
>
> FWIW, I think it's better to have the DLLs and their sources available
> in separate archives, not in a single large one, because some users
> may wish to install only part of the libraries.  But that's me.


My inclination would be to provide three files.

emacs-*-bin.tar.gz -- as is now (with libnoX4)
emacs-*-libraries.tar.gz -- with binaries for libraries
emacs-*-libraries.sources.tar.gz -- with sources for the libraries

Phil

Re: Emacs binaries for Windows

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: Arash Esbati <arash.esbati@gmail.com>,  emacs-devel@gnu.org
> Date: Mon, 22 Aug 2016 11:37:47 +0100
> 
> > FWIW, I think it's better to have the DLLs and their sources available
> > in separate archives, not in a single large one, because some users
> > may wish to install only part of the libraries.  But that's me.
> 
> 
> My inclination would be to provide three files.
> 
> emacs-*-bin.tar.gz -- as is now (with libnoX4)
> emacs-*-libraries.tar.gz -- with binaries for libraries
> emacs-*-libraries.sources.tar.gz -- with sources for the libraries

No, I meant each library in a separate archive.  Again, that's just my
opinion, something I do all the time on the ezwinports site.

Re: Emacs binaries for Windows

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: Arash Esbati <arash.esbati@gmail.com>,  emacs-devel@gnu.org
>> Date: Mon, 22 Aug 2016 11:37:47 +0100
>> 
>> > FWIW, I think it's better to have the DLLs and their sources available
>> > in separate archives, not in a single large one, because some users
>> > may wish to install only part of the libraries.  But that's me.
>> 
>> 
>> My inclination would be to provide three files.
>> 
>> emacs-*-bin.tar.gz -- as is now (with libnoX4)
>> emacs-*-libraries.tar.gz -- with binaries for libraries
>> emacs-*-libraries.sources.tar.gz -- with sources for the libraries
>
> No, I meant each library in a separate archive.  Again, that's just my
> opinion, something I do all the time on the ezwinports site.

Would that not be a pain to install? You have to unpack them all
separately? Irritating from the desktop.

Phil

Re: Emacs binaries for Windows

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: arash.esbati@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 23 Aug 2016 12:26:00 +0100
> 
> >> emacs-*-bin.tar.gz -- as is now (with libnoX4)
> >> emacs-*-libraries.tar.gz -- with binaries for libraries
> >> emacs-*-libraries.sources.tar.gz -- with sources for the libraries
> >
> > No, I meant each library in a separate archive.  Again, that's just my
> > opinion, something I do all the time on the ezwinports site.
> 
> Would that not be a pain to install? You have to unpack them all
> separately? Irritating from the desktop.

Not sure why this would be a pain.  Unpacking .tar.gz files is already
a pain on Windows (which is why ezwinports uses only *.zip files,
which can be unpacked with the Windows Explorer).  But once that
obstacle has been negotiated, why does it matter whether one needs to
unpack one file or a dozen?

The advantage is that since the libraries don't have to change too
frequently, you can unpack them only once, and after that only install
the Emacs binary, leaving the libraries intact.

Re: Emacs binaries for Windows

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: arash.esbati@gmail.com,  emacs-devel@gnu.org
>> Date: Tue, 23 Aug 2016 12:26:00 +0100
>> 
>> >> emacs-*-bin.tar.gz -- as is now (with libnoX4)
>> >> emacs-*-libraries.tar.gz -- with binaries for libraries
>> >> emacs-*-libraries.sources.tar.gz -- with sources for the libraries
>> >
>> > No, I meant each library in a separate archive.  Again, that's just my
>> > opinion, something I do all the time on the ezwinports site.
>> 
>> Would that not be a pain to install? You have to unpack them all
>> separately? Irritating from the desktop.
>
> Not sure why this would be a pain.  Unpacking .tar.gz files is already
> a pain on Windows (which is why ezwinports uses only *.zip files,
> which can be unpacked with the Windows Explorer).  But once that
> obstacle has been negotiated, why does it matter whether one needs to
> unpack one file or a dozen?

I think another issue would be making every single archive
self-contained then.  The way I understand it many (all?) DLLs rely on
`libgcc_s_seh-1.dll'.  So this one must be packed in every archive.  I
think your ezwinports are built this way.

For the start, I think I go with Phil: Pack the DLLs into one archive
and tell users to unpack them into the directory where emacs.exe resides
and be done with it.  This procedure can be changed later, if necessary.

Just my 2 cents.

Best, Arash

Re: Emacs binaries for Windows

[Eli Zaretskii]

> From: Arash Esbati <arash.esbati+ml@gmail.com>
> Cc: phillip.lord@russet.org.uk (Phillip Lord),  emacs-devel@gnu.org
> Date: Tue, 23 Aug 2016 19:02:52 +0200
> 
> I think another issue would be making every single archive
> self-contained then.

Yes, the dependency DLLs should be in every archive.  But if they are
identical, there's no problem for the users.

> The way I understand it many (all?) DLLs rely on
> `libgcc_s_seh-1.dll'.  So this one must be packed in every archive.
> I think your ezwinports are built this way.

Actually, I normally go to great lengths to avoid the runtime
dependency on the libgcc DLL.  For two reasons: (a) people who have
GCC installed will have that DLL, but probably a different version of
it; and (b) more importantly, the GPL mandates that distributing the
libgcc DLL requires to have the entire sources of GCC available from
the same site, and those sources are huge.

> For the start, I think I go with Phil: Pack the DLLs into one archive
> and tell users to unpack them into the directory where emacs.exe resides
> and be done with it.  This procedure can be changed later, if necessary.

It's up to whoever does the job, I was just explaining my personal
views.

Re: Emacs binaries for Windows

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: phillip.lord@russet.org.uk (Phillip Lord)
>> Cc: arash.esbati@gmail.com,  emacs-devel@gnu.org
>> Date: Tue, 23 Aug 2016 12:26:00 +0100
>> 
>> >> emacs-*-bin.tar.gz -- as is now (with libnoX4)
>> >> emacs-*-libraries.tar.gz -- with binaries for libraries
>> >> emacs-*-libraries.sources.tar.gz -- with sources for the libraries
>> >
>> > No, I meant each library in a separate archive.  Again, that's just my
>> > opinion, something I do all the time on the ezwinports site.
>> 
>> Would that not be a pain to install? You have to unpack them all
>> separately? Irritating from the desktop.
>
> Not sure why this would be a pain.  Unpacking .tar.gz files is already
> a pain on Windows (which is why ezwinports uses only *.zip files,
> which can be unpacked with the Windows Explorer).  But once that
> obstacle has been negotiated, why does it matter whether one needs to
> unpack one file or a dozen?


Ah, yes, sorry would intend to distribute as a zip, not a tgz.

Phil