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 14:07:15 +0200 Message-ID: <83r4j2z7nw.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> 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 1364299640 23886 80.91.229.3 (26 Mar 2013 12:07:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Mar 2013 12:07: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 13:07:47 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 1UKSfK-0001mr-BP for ged-emacs-devel@m.gmane.org; Tue, 26 Mar 2013 13:07:46 +0100 Original-Received: from localhost ([::1]:46088 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKSew-00007o-BZ for ged-emacs-devel@m.gmane.org; Tue, 26 Mar 2013 08:07:22 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKSer-00007R-11 for emacs-devel@gnu.org; Tue, 26 Mar 2013 08:07:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKSeo-0000Li-V3 for emacs-devel@gnu.org; Tue, 26 Mar 2013 08:07:16 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:47099) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKSeo-0000LW-MC for emacs-devel@gnu.org; Tue, 26 Mar 2013 08:07:14 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MK900M00OBNJ500@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Tue, 26 Mar 2013 14:07:02 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MK900M65OBPAG70@a-mtaout20.012.net.il>; Tue, 26 Mar 2013 14:07:02 +0200 (IST) In-reply-to: <87obe6ben5.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.166 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:158200 Archived-At: > From: =D3scar Fuentes > Date: Tue, 26 Mar 2013 12:10:22 +0100 >=20 > Eli Zaretskii writes: >=20 > >> Just for the record: this problem does not exist in the GNU/Linu= x build > >> procedure. More specifically, in the Unix makefiles, "make boot= strap" > >> kind of like "make clean; make". So presumably, by suitably cha= nging > >> the Windows makefiles to mimick what the Unix makefiles do, we s= hould be > >> able to get the same behavior. > > > > Can't be done without a lot of non-trivial hacking, if at all > > possible. The Unix makefiles use Borne shell features to get thi= s > > done, and I don't want to require Windows users to have a native > > Windows port of a Unixy shell installed (because there are no goo= d > > ones). > > > > That said, feel free to donate patches to make this happen. > > > >> Of course, making it possible to build the Windows version via > >> ./configure would also solve it. > > > > In the works, but I could use some help. The main problem, which= I'm > > still unsure what is the best way of solving, is how to tell conf= igure > > not to test for certain features and instead accept that the test > > should succeed (because those features are implemented in Emacs > > sources). >=20 > It seems to me that your two paragraphs contradict: on the first yo= u say > that you don't want a Bourne shell on Windows, but in the second yo= u say > that you are working on running the ./configure script on Windows (= which > maybe does not require a Bourne shell, but some kind on Unix shell > anyway.) 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. > 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. > Instead on trying to force a square peg into a round hole, why not = using > something native to Windows such as CMake, which adds a single, wel= l > defined dependency to the build, and allows proper platform checks, > scriptability, etc.? 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 se= e no significant advantage going that way, unless mainline Emacs development switches to CMake. 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 o= f the head maintainers understands well, or wants to. That is a huge gain, which might just countermand the disadvantage of asking users t= o install MSYS. > I know that this proposal was rejected twice before, but I'll bet t= hat > 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. However, my experience does not support your bet. Running the curren= t 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. There's an easy way of forcing the configure script to pass tests without trying (set the corresponding ac_* variables before running the script). But what I'd like to do is to maintain a text file with a list of functions, header files, and other features that are implemented in Emacs's own sources, and provide an automated way to set those autoconf variables from that list. This way, whenever a ne= w feature is added, all that will be need is to add a few lines to the list. Or maybe there's an easier/more elegant method of skipping autoconf tests with known results. I'm all ears.