From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: Anyone building Emacs trunk with MinGW w64 (32 bits) Date: Tue, 26 Mar 2013 13:34:02 +0100 Message-ID: <87fvzibarp.fsf@wanadoo.es> References: <87zjxumbjf.fsf@wanadoo.es> <83vc8f1t0x.fsf@gnu.org> <87wqsvcso0.fsf@wanadoo.es> <83fvzj1atq.fsf@gnu.org> <83zjxqzn2y.fsf@gnu.org> <87obe6ben5.fsf@wanadoo.es> <83r4j2z7nw.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1364301263 7828 80.91.229.3 (26 Mar 2013 12:34:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Mar 2013 12:34:23 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 26 13:34:50 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UKT5U-00039A-Iw for ged-emacs-devel@m.gmane.org; Tue, 26 Mar 2013 13:34:48 +0100 Original-Received: from localhost ([::1]:53110 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKT56-0007Vw-L4 for ged-emacs-devel@m.gmane.org; Tue, 26 Mar 2013 08:34:24 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37066) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKT53-0007Ro-3T for emacs-devel@gnu.org; Tue, 26 Mar 2013 08:34:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKT50-0000Vp-Mc for emacs-devel@gnu.org; Tue, 26 Mar 2013 08:34:21 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:57227) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKT50-0000VX-GC for emacs-devel@gnu.org; Tue, 26 Mar 2013 08:34:18 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UKT5K-0002qP-FB for emacs-devel@gnu.org; Tue, 26 Mar 2013 13:34:38 +0100 Original-Received: from 87.red-88-15-56.dynamicip.rima-tde.net ([88.15.56.87]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Mar 2013 13:34:38 +0100 Original-Received: from ofv by 87.red-88-15-56.dynamicip.rima-tde.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 26 Mar 2013 13:34:38 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 73 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 87.red-88-15-56.dynamicip.rima-tde.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:aJ/9nabERPeFwl4XpN6q0ODkf6Q= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:158201 Archived-At: Eli Zaretskii writes: > There's no contradiction. These are 2 different situations involved > here: the first one where Windows-specific makefiles are used with > native Windows tools, the second one where Unix makefiles are used > with tools that can produce and grok them. Okay. >> What new requirements would add running ./configure on Windows, as per >> your plan? > > MSYS and the auxiliary MSYS tools will have to be installed on the > end-user system. Ugh! I strive to keep my machines Cygwin and MSYS-free (being MSYSGit the only allowed trespasser, for obvious reasons.) I'm not saying that I'll stop building Emacs the day MSYS becomes a requirement, but you'll admit that it is a heavy, potentially problematic one. > I've used CMake in a package much less complex than Emacs (Gawk, if > you want to know), and my conclusion was that it also requires some > non-trivial amount of tinkering, in order to work well with the MinGW > development environment. And that tinkering needs good knowledge of > CMake, something not easily gleaned from the available docs. So I see > no significant advantage going that way, unless mainline Emacs > development switches to CMake. I'm not saying that it would be trivial. And some MinGW-specific tinkering would be necessary, yes. But for the user it would be hassle-free (well, CMake with the "MinGW Makefiles" generator doesn't want a `sh.exe' on your PATH, but it explicitly tells you so when you start the build.) > By contrast, using the Posix configure script and Posix Makefile.in > files will relieve us from at least one of the duties: the need to > track mainline development in a separate set of scripts that no one of > the head maintainers understands well, or wants to. That is a huge > gain, which might just countermand the disadvantage of asking users to > install MSYS. I'm not inclined to adding responsibilites to the users for the (understandable) convenience of the developers, if other options exists. Rather I'll prefer a system that is easy enough to maintain so the hassle becomes less serious. And then, if the system is cross-platform and there are developers who enjoy using it for their hacking, you'll get some help for free. >> I know that this proposal was rejected twice before, but I'll bet that >> making ./configure work on Windows would require less work than a >> complete CMake build specification for Emacs. > > I guess you meant "less work" for CMake, not for ./configure. Yes, sorry. > However, my experience does not support your bet. Running the current > configure script with MSYS tools is actually a no-brainer: I already > tried that, and it worked out of the box with no need to change > anything. > > The only issue is what I mentioned above: that the configure script > probes the development environment, where many features are missing, > features that were implemented in the Emacs sources instead. One such thing is easily abstractable (sp?) on CMake: "run this platform check unless this or that condition holds, for which the answer is that." The declarative/procedural nature of CMake makes so much things trivial to implement compared against autotools/automake.