> Date: Thu, 9 Oct 2014 11:29:56 +0200 > From: Alexander Shukaev <haroo...@gmail.com> > > 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 branch. . 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.