[Top][All Lists]

[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:01:16 +0300

> Date: Thu, 9 Oct 2014 11:29:56 +0200
> From: Alexander Shukaev <address@hidden>
> Now I would like to spread out news that I've started Emacs for Windows. It
> aims to provide high-quality native builds of Emacs for Windows, and once
> again, x86 (32-bit) and x64 (64-bit) architectures are supported (unlike
> official binaries). Many external features and their corresponding runtime
> (shared) libraries (DLLs) are already included, so there is no need to search
> through different binary repositories to get up-to-date GnuTLS, for example, 
> or
> DBUS, and many others.

(DBUS?  Emacs on Windows doesn't support DBUS, AFAIK.)

> These features have lots of runtime dependencies,
> building which is quite cumbersome (if possible at all) for inexperienced
> users. From now on, all of that is included in my distributions.
> I'm looking forward to some feedback, if anybody finds that useful and wants 
> me
> to continue to support that project actively. It does not mean that I'm going
> to drop that at all otherwise (since I'm using it as well for myself), but if
> there is lack of public interest, then I would probably update it much rarer
> than I could otherwise.

I think providing high-quality binaries for Emacs is very useful, and
will be appreciated, thanks.

Allow me a few comments:

  . The binaries must be produced from unpatched upstream sources,
    because otherwise the Emacs maintainers will be reluctant to deal
    with any bug reports and questions about the binaries.  This means
    if you want to fix some bugs, you must report them upstream, not
    fix them locally.  Alternatively, you should be prepared to deal
    with those questions and bug reports yourself.

  . For binaries produced from the repository (as opposed to official
    released tarballs), it is best to include some unique indication
    of the last commit included in the binary, like bzr revno or git
    sha1 or the exact time stamp of the last commit or checkout.
    Otherwise, users will have hard time answering questions about the
    exact version they are running, or figuring out whether a specific
    bug is already fixed in their binary, etc.

  . Binaries produced from the Emacs development trunk tend to be
    broken from time to time, so it is at least no less important to
    have binaries from the last official release and/or the release

  . You seem to favor a directory hierarchy where each package has its
    own parent directory with the bin/ subdirectory under it.  This
    has some advantages (like avoiding the "DLL hell" and allowing you
    to update the DLLs as you see fit), but it also has clear
    disadvantages: a much longer PATH, INFOPATH, MANPATH, etc.; the
    need to use multiple -I and -L switches when using the headers and
    libraries; multiple copies of potentially identical DLLs; etc.  I
    think at the very least you should explain these issues on the
    download page, so people could arrange their systems as they would
    like, and still have a coherent system where different programs
    work together seamlessly.

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

Once again, thanks for doing this important job.

reply via email to

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