From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: emacs-win-builder Date: Wed, 31 Aug 2016 17:17:03 +0300 Message-ID: <83y43dkops.fsf@gnu.org> References: <1137fded-fc14-2445-bc6b-e8f2aceed56c@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1472653059 10444 195.159.176.226 (31 Aug 2016 14:17:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 31 Aug 2016 14:17:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Nikolay Kudryavtsev Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 31 16:17:29 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bf6KO-00018M-DT for ged-emacs-devel@m.gmane.org; Wed, 31 Aug 2016 16:17:20 +0200 Original-Received: from localhost ([::1]:54369 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bf6KM-00006X-3k for ged-emacs-devel@m.gmane.org; Wed, 31 Aug 2016 10:17:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47304) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bf6KF-00006E-JA for emacs-devel@gnu.org; Wed, 31 Aug 2016 10:17:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bf6K9-00060T-ER for emacs-devel@gnu.org; Wed, 31 Aug 2016 10:17:10 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44035) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bf6K9-00060P-B6; Wed, 31 Aug 2016 10:17:05 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2857 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bf6K8-0002P1-F4; Wed, 31 Aug 2016 10:17:05 -0400 In-reply-to: <1137fded-fc14-2445-bc6b-e8f2aceed56c@gmail.com> (message from Nikolay Kudryavtsev on Tue, 30 Aug 2016 22:47:48 +0300) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207025 Archived-At: > From: Nikolay Kudryavtsev > Date: Tue, 30 Aug 2016 22:47:48 +0300 > > Ladies and gentlemen, presenting emacs-win-builder, an Elisp script for building Emacs on Windows. Currently I published it here. > > The general idea is very simple. You start with only wget installed and Emacs sources, run a single function and get a new version of Emacs built for you. This installs the appropriate toolchain(MinGW and Msys2 are both supported), then goes through the whole autogen -> configure -> make -> make install cycle. > > I believe this would save some time, both for maintainers of Emacs on Windows and general users. This also allows Emacs developers to keep the build procedure as complex as required, without having to worry about making it too hard for users to follow. Also, this lowers the dependency on any toolchain, since we can always add some of our own patches or non standard versions of packages into the process(MinGW build already uses quite few of them). People who want to hack around the build process would always have a working place to start from. Also users would be able to test bug fixes immediately without having to wait for a third party or the next RC. > > Currently there are a few hacky pats, some parts should be better documented, but the main build procedure works for every currently possible build. Out of optional things, for MinGW only gnutls is currently built, but this is solvable. Also, I'm not so sure on the versions of MinGW libraries, this needs review from someone with better knowledge. I haven't thoroughly tested the resulting builds, but since this script does not do any magic, any possible problems with them seem solvable. Thanks. I have no problem with offering this in nt/ as an alternative build method, provided that it is mentioned in nt/INSTALL and nt/INSTALL.W64. I have a few comments to the script and its concept: . It invokes MSYS programs from a (presumably) native Emacs, something that might not necessarily work, depending on the end-user setup. E.g., on my systems, MSYS can only work when invoked from the MSYS Bash window. Caveat emptor! . Your function that invokes the various commands ignores the return value of process-file-shell-command, so if some part of the build fails, the script will happily continue invoking the rest of the build commands regardless. Also, it looks like the output of the build commands is not shown as the build proceeds, which means the user is building blind and cannot interrupt a runaway build. Wouldn't it be better to use start-file-process instead? . The list of dependencies to download should IMO be on a separate file and in a format that can be easily changed by someone who is not too proficient in Lisp, because the dependencies change and their versions change even more frequently. The repeated portions of the URLs of the download sites could also be specified only once in that separate file. . Various versions of 7z are not Free Software, so I think we'd prefer to use bsdtar from libarchive instead. As a bonus, users will be saved from the UAC elevation prompts when installing the package (at least with libarchive available from the ezwinports site). . This comment: (process-file-shell-command (concat "\"" (ewb-get-wget) "\" --no-check-certificate " file ;; ezwinports version of wget needs -O flag ;; otherwise it saves files as "download" " -O" file-name) nil "ewb") made me raise my brow: I use that version of wget all the time, and it certainly does NOT save files as "download". So some other factor is at work here, most probably the download URLs that all end in "/download". A better URL is something like this: http://downloads.sourceforge.net/project/ezwinports/FILE where FILE is the file you want to download, like zlib-1.2.8-2-w32-bin.zip. . Last but not least: AFAIK, Windows will not allow you to install executables and DLLs that overwrite running modules. So, for example, running "make install" from an Emacs that lives in the same directory as where "make install" will copy the newly-built executable will fail, and I think likewise with DLLs that are in use by the running Emacs process. Users should be aware of that caveat, and maybe the script should install in some staging area, leaving it to the user to copy to the final destination after exiting Emacs. Thanks again for working on this. I urge people here to try your script and return feedback.