From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Anyone building Emacs trunk with MinGW w64 (32 bits) Date: Tue, 26 Mar 2013 15:24:14 +0200 Message-ID: <83li9az43l.fsf@gnu.org> 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> <87fvzibarp.fsf@wanadoo.es> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1364304260 7731 80.91.229.3 (26 Mar 2013 13:24:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Mar 2013 13:24:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 26 14:24:45 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 1UKTrm-0006gx-1f for ged-emacs-devel@m.gmane.org; Tue, 26 Mar 2013 14:24:42 +0100 Original-Received: from localhost ([::1]:57513 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKTrO-0006HZ-1L for ged-emacs-devel@m.gmane.org; Tue, 26 Mar 2013 09:24:18 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKTrF-0006Fr-Hv for emacs-devel@gnu.org; Tue, 26 Mar 2013 09:24:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKTr9-0001tp-Mr for emacs-devel@gnu.org; Tue, 26 Mar 2013 09:24:09 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:59569) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKTr9-0001sU-F2 for emacs-devel@gnu.org; Tue, 26 Mar 2013 09:24:03 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MK900B00RLWRL00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 26 Mar 2013 15:24:01 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MK900BG2RW11LC0@a-mtaout22.012.net.il>; Tue, 26 Mar 2013 15:24:01 +0200 (IST) In-reply-to: <87fvzibarp.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:158209 Archived-At: > From: =D3scar Fuentes > Date: Tue, 26 Mar 2013 13:34:02 +0100 >=20 > >> 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 th= e > > end-user system. >=20 > Ugh! I strive to keep my machines Cygwin and MSYS-free (being MSYSG= it > the only allowed trespasser, for obvious reasons.) If you have MSYSGit installed, then resisting MSYS is kinda pointless= , don't you think? Because you already have most of MSYS, and then some. > 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 agree that it's a disadvantage. But most Free Software packages already require to have MSYS installed to build a native MinGW port, so it's not like Emacs will be the first offender here. > > 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 so= me > > non-trivial amount of tinkering, in order to work well with the M= inGW > > 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. >=20 > 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 y= ou > start the build.) For the user it is hassle-free already. In fact, it is even more hassle-free than it could ever be with CMake: it doesn't require CMak= e to be installed and configured. (And if you think that's a no-brainer, then ask me to tell you a horror story how I wasted an hour trying to get CMake to work with my fully-functional MinGW installation, due to a very subtle issue, not mentioned anywhere in the docs and not found by Google.) > > By contrast, using the Posix configure script and Posix Makefile.= in > > files will relieve us from at least one of the duties: the need t= o > > track mainline development in a separate set of scripts that no o= ne of > > the head maintainers understands well, or wants to. That is a hu= ge > > gain, which might just countermand the disadvantage of asking use= rs to > > install MSYS. >=20 > I'm not inclined to adding responsibilites to the users for the > (understandable) convenience of the developers, if other options ex= ists. "Developer's convenience" my foot. From my perspective, what's at stake is the ability of keeping a viable Windows port alive! How man= y contributors to Emacs even understand the Windows build procedure wel= l enough to develop and maintain it? Asking users who build their own Emacs on Windows to install MSYS is a small price for making sure the Windows port will be able to keep up with the Posix build procedure for free. For people who don't want to pay that price, there will always be binary distributions. > One such thing is easily abstractable (sp?) on CMake: "run this pla= tform > check unless this or that condition holds, for which the answer is > that." Right, but when you get to implement the condition, you get burned. Sorry, I'm not convinced, and this time based on my own bitter, though eventually successful enough, experience.