help-emacs-windows
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [h-e-w] Emacs for Windows


From: Eli Zaretskii
Subject: Re: [h-e-w] Emacs for Windows
Date: Thu, 09 Oct 2014 14:48:03 +0300

> Date: Thu, 9 Oct 2014 13:16:38 +0200
> From: Alexander Shukaev <address@hidden>
> 
>     DBUS? Emacs on Windows doesn't support DBUS, AFAIK.
> 
> Well, DBUS exists for Windows, it can be built for Windows and I have it 
> built.
> I have included DBUS as a feature during configuration stage and I have also
> linked it statically into the Emacs executable, not to introduce another
> additional DLL.

That's wonderful.  Do all the DBUS features work as expected?  Did you
succeed to pass all the tests in the testsuite (dbus-tests.el)?

In the Windows build, we generally don't like statically linking
against optional libraries, we load them dynamically if and when
needed.  So it would be good if you could add the necessary code to do
that with DBUS, and submitted the patches for inclusion.  The changes
are quite mechanical, you can see in image.c and in gnutls.c how this
is done.  TIA.

>     Last, but not least: the GPL requires you to have the sources
>     available for every package whose binaries you post, and have all
>     the source-level changes you made while building those binaries in
>     those source tarballs. I don't see any source distributions on
>     your download page, maybe I missed something.
> 
> Do I have to upload sources for Emacs and all the DLLs (which are under GPL)
> just to fulfill this requirement?

Unfortunately, yes.  The letter of the license actually allows you to
provide only a pointer to the sources, but that is impractical when
you build from a repository, and also because even source
distributions of some official releases can vary between different
download sites (this happens a lot with GTK-related packages, for
example).

OTOH, producing the source distro is very easy: just zip your source
tree after making the binary, then delete the binary files (*.o,
*.exe, *.a, *.dll, etc.), and that's all.

> That would be a huge waste of space/time for me. Is this so strict?

It does put pressure on the necessary space, yes.  But I think this is
an effort well spent in the long run, because you let your users see
what you compiled, and compare it with other similar packages, which
is important when some problems happen in certain builds, but not in
others.  E.g., just a couple of days ago I had a problem that I fixed
in the Windows build of Bison 3.0.2, which didn't seem to exist in the
binary provided by MinGW64.  But I couldn't see if the problem didn't
exist there because they fixed it like I did, or because they used
some hidden feature of the MinGW64 libraries, or for any other reason,
because there was no source distro corresponding to those binaries
anywhere in sight!

More generally, if one of your users will want to take your package
and make a very small change in it, they will be unable to do that
without the exact sources you used.  So by and large, this is about
user freedom, which is what the GPL strives to protect.

Btw, this is the reason why the binaries I make available are never
dependent on libgcc_s_dw2-1.dll -- because having that dependency
means you need to upload the humongous 80MB source distro of GCC as
well (yes, LGPL is not applicable to shared library versions of
libgcc).  (I can tell you how to avoid that dependency, if you don't
already know.)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]