From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Hannu Koivisto Newsgroups: gmane.emacs.devel Subject: Re: A few Windows build fixes Date: Mon, 29 Aug 2011 15:03:07 +0300 Organization: NOYB Message-ID: <83mxes4e84.fsf@kalahari.s2.org> References: <83vcth40ik.fsf@kalahari.s2.org> <83r5444ome.fsf@kalahari.s2.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1314619418 31051 80.91.229.12 (29 Aug 2011 12:03:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 29 Aug 2011 12:03:38 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 29 14:03:34 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Qy0Yt-0005CY-Tj for ged-emacs-devel@m.gmane.org; Mon, 29 Aug 2011 14:03:32 +0200 Original-Received: from localhost ([::1]:39326 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qy0Yt-0005RL-1G for ged-emacs-devel@m.gmane.org; Mon, 29 Aug 2011 08:03:31 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:53290) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qy0Yo-0005Lq-G7 for emacs-devel@gnu.org; Mon, 29 Aug 2011 08:03:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qy0Ym-0007Pg-Qc for emacs-devel@gnu.org; Mon, 29 Aug 2011 08:03:26 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:52883) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qy0Ym-0007Pb-7v for emacs-devel@gnu.org; Mon, 29 Aug 2011 08:03:24 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1Qy0Yk-00058d-RV for emacs-devel@gnu.org; Mon, 29 Aug 2011 14:03:22 +0200 Original-Received: from s2.org ([80.83.7.53]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2011 14:03:22 +0200 Original-Received: from azure by s2.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 29 Aug 2011 14:03:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 156 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: s2.org User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.3 (gnu/linux) Cancel-Lock: sha1:Ek5Yob5PIr2R0vogai8h0wpQyio= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:143624 Archived-At: Eli Zaretskii writes: >> From: Hannu Koivisto >> Date: Mon, 29 Aug 2011 11:18:33 +0300 > trouble. By contrast, GnuWin32 is a collection of native Windows > ports of GNU software. They don't "fix" any file names, and they > support native Windows file name format, either with forward slashes > or with backslashes. That sounds very good compared to msys. However, I have no need for such native tools so I'm not going to install them and test with them. >> In any case, it's my opinion that trying to support all these >> different environments with the same makefiles (assuming that >> something like cmake or similar, which is able to create real >> makefiles for native tools from a higher level description, is not >> used) only leads to trouble. > > Again, there's no trouble with GnuWin32 ports that I'm aware of. I > use them every day to build Emacs. The fact that you see one environment working fine and I see others failing is precisely the problem I'm talking about. The makefiles would be better off separated into environment specific parts and environment independent parts so that users of one environment could fix their environment specific parts or generic parts without worrying too much about breaking other environments (like I've just done with GnuWin32). Unfortunately this is nontrivial or at least ugly with plain make. >> >> +if %MAKECMD% == gmake dos2unix config.tmp config.settings >> > >> > This requires users to have dos2unix installed, even if they don't use >> > the Cygwin tools to build Emacs. If there's another way of doing this >> >> I recall I tested that failure to find dos2unix doesn't stop bat >> execution, but maybe I remember incorrectly. > > Even if it doesn't, it is a bad mojo to generate error messages that > need to be ignored. Can this be conditioned on Cygwin alone, please? Sure. >> CURDIR-based paths are passed to native Emacs for load path >> purposes and if they have /cygdrive/ stuff in them, Emacs doesn't >> understand that. > > Is it possible to use a native port of GNU Make with Cygwin GCC? I suppose it's possible but at least I'm not interested in setting up such a mixed environment. I can't speak for other Cygwin users but with my user hat on, either building works with standard "out of the box" Cygwin installation or it doesn't. > Would that solve the problem? How about using `cygpath' to convert > the file names when Cygwin tools are used? Well, that's what I decided to do with install directory, but in this case there were so many places that I was reluctant to sprinkle the makefiles with cygpath stuff and rather tried to avoid the whole conflict by using relative paths. If that doesn't work in general, I'm fine with that; my goal was only to build Emacs in at least one environment that I have in use. > The main toolchain that is currently supported for building the native > Windows port of Emacs is MinGW accompanied by a few GnuWin32 ports > (`cp', `rm', `mv'). So supporting MinGW which needs this, > is indeed more important than supporting the build with Cygwin, yes. I think you should consider replacing the current largely obsolete INSTALL file and mention only this one supported build environment. > Probably because you only used the Cygwin and MSYS ports of Make. > With the native port of Make (you can download it from the MinGW site > or build it yourself from sources), just removing sh.exe from PATH I installed mingw+msys using a graphical installer where one could select mingw, msys and some development tools thing. I guess the native port of make is not installable through this mechanism, unless it is part of the development tools thing (whose contents wasn't explained) and available under some other name or in some other directory that I didn't have in path. Not that this really matters, I have no need for mingw, I have standardized my setup to platform's native tools (Visual C++) or Cygwin. Thanks for the information regarding msys and native make though, it may become useful later. > We already support cmd.exe with GNU Make, see the SHELLTYPE variable. > In fact, I think we should gradually remove the support for sh.exe, > because the number of good native Windows ports of a Posix shell is > close to zero, and cmd.exe support in the native port of GNU Make is > quite good. That sounds good, currently the makefiles are quite a mess. Of course I won't be able to build Emacs unless cmd.exe works also with Cygwin GNU Make or Visual C++ build is fixed but simplifying the build system is more important than builds working in my environment. >> > There are more places where you use "mkdir -p"; please find some other >> > solution for that particular problem, or let's leave it unsolved, as >> > no one has complained until now, AFAIR. >> >> Not solving this means that "make install" won't work when cmd is >> not used. > > It will work if INSTALL_DIR already exists. Actually it doesn't, because the makefiles try to create the same directory (at least $INSTALL_DIR/bin, possibly others) several times. >> >> +INSTALL_DIR_MIXED := $(INSTALL_DIR) >> >> +ifeq "$(shell cygpath $(INSTALL_DIR))" "$(INSTALL_DIR)" >> >> +INSTALL_DIR_MIXED := $(shell cygpath -m "$(INSTALL_DIR)") >> >> +endif >> > >> > I don't understand the need for this gork. Please explain. Is the >> > Cygwin build supposed to use Cygwin `cp' etc., or their native >> > versions? >> > >> > In any case, why do we need both INSTALL_DIR and INSTALL_DIR_MIXED? >> >> When used in makefile rules, Cygwin style path is needed, and when >> passing the path to native binaries like addpm etc that are used >> during installation, a mixed style path is needed. > > Again, will using the native build of Make solve this? Perhaps, I don't have one. > If not, is it possible to define a macro that on Cygwin will run the > file name through `cygpath'? I'm sure it is. >> > If both are needed, we will need a corresponding change in nmake.defs. >> >> I don't think changes are needed in nmake.defs, Cygwin style paths >> should not be involved there. > > But INSTALL_DIR_MIXED will be in makefile.w32-in, which is used by > nmake build as well. Right, that would clearly need to be fixed. I'm not going to work on these changes in the foreseeable future, though, so don't expect updated versions soon. In fact, if I'll work on building Emacs on Windows later, I think I'd rather use my time on trying to fix the Visual C++/nmake build, which was my primary choice anyway. -- Hannu