A few Windows build fixes

A few Windows build fixes

[Hannu Koivisto]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

Greetings,

I wanted to build the latest bzr trunk version of Emacs for Windows
but soon realized that the makefiles and the configure process have
lots of problems.

I'm attaching four patches that fix enough of the problems that
building and installing with a modern Cygwin (I'm talking about
building and installing a native Windows binary, not a Cygwin one)
works now.  Mingw/MSYS remains broken (I started to fix that too
but got disgusted by MSYS' automatic path conversion that cannot
even be toggled off, and decided not to continue).  Visual
C++/nmake combination is broken too but the first problems I faced
were not related to the build system but Visual Studio .NET 2003's
inability to compile the code (some missing types, use of inline
keyword).  Perhaps later versions work better.  I'll try that when
I get my hands on one.

The patches were generated with git format-patch (and thus include
commit messages that provide information about what was done) but
they can be applied with "patch -p1" to a Bazaar repository.  They
are as attachments because some of them change line endings from
CRLF to LF and I'm hoping to avoid any screwups with that.  In case
you find them useful, note that I haven't signed papers with FSF
(I'm hoping I don't have to, as the majority of the changes are
rather systematic search&replace operations).

Hannu


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-NT-build-support-modern-Cygwins-where-gcc-is-a-symli.patch --]
[-- Type: text/x-diff, Size: 3362 bytes --]

From 90258756a199738e4cb7ae406893827d9ef83cc3 Mon Sep 17 00:00:00 2001
From: Hannu Koivisto <azure@iki.fi>
Date: Sun, 28 Aug 2011 23:00:00 +0300
Subject: [PATCH 1/4] NT build: support modern Cygwins where gcc is a symlink

---
 nt/configure.bat |   35 ++++++++++++++++++++++-------------
 1 files changed, 22 insertions(+), 13 deletions(-)

diff --git a/nt/configure.bat b/nt/configure.bat
index 45d966f..9db688f 100755
--- a/nt/configure.bat
+++ b/nt/configure.bat
@@ -89,6 +89,7 @@ echo. character by enclosing them in quotes will not be supported.
 
 rem ----------------------------------------------------------------------
 rem   Default settings.
+set gccbin=gcc
 set prefix=
 set nodebug=N
 set noopt=N
@@ -379,6 +380,14 @@ echo main(){} >junk.c
 gcc -c junk.c
 if exist junk.o goto checkgcc
 
+gcc-3 -c junk.c
+set gccbin=gcc-3
+if exist junk.o goto checkgcc
+
+gcc-4 -c junk.c
+set gccbin=gcc-4
+if exist junk.o goto checkgcc
+
 echo Checking whether 'cl' is available...
 cl -nologo -c junk.c
 if exist junk.obj goto clOK
@@ -394,11 +403,11 @@ if (%nocygwin%) == (Y) goto chkapiN
 echo Checking whether gcc requires '-mno-cygwin'...
 echo #include "cygwin/version.h" >junk.c
 echo main(){} >>junk.c
-echo gcc -c junk.c >>config.log
-gcc -c junk.c >>config.log 2>&1
+echo %gccbin% -c junk.c >>config.log
+%gccbin% -c junk.c >>config.log 2>&1
 if not exist junk.o goto chkapi
-echo gcc -mno-cygwin -c junk.c >>config.log
-gcc -mno-cygwin -c junk.c >>config.log 2>&1
+echo %gccbin% -mno-cygwin -c junk.c >>config.log
+%gccbin% -mno-cygwin -c junk.c >>config.log 2>&1
 if exist junk.o set nocygwin=Y
 
 :chkapi
@@ -430,10 +439,10 @@ set cf=%usercflags% -mno-cygwin
 
 :chkapi2
 echo on
-gcc %cf% -c junk.c
+%gccbin% %cf% -c junk.c
 @echo off
-@echo gcc %cf% -c junk.c >>config.log
-gcc %cf% -c junk.c >>config.log 2>&1
+@echo %gccbin% %cf% -c junk.c >>config.log
+%gccbin% %cf% -c junk.c >>config.log 2>&1
 set cf=
 if exist junk.o goto chkuser
 echo The failed program was: >>config.log
@@ -445,8 +454,8 @@ rm -f junk.o
 echo int main (int argc, char *argv[]) {>junk.c
 echo char *usercflags = "%escusercflags%";>>junk.c
 echo }>>junk.c
-echo gcc -Werror -c junk.c >>config.log
-gcc -Werror -c junk.c >>config.log 2>&1
+echo %gccbin% -Werror -c junk.c >>config.log
+%gccbin% -Werror -c junk.c >>config.log 2>&1
 if exist junk.o goto gccOk
 echo.
 echo Error in --cflags argument: %usercflags%
@@ -471,8 +480,8 @@ rm -f junk.c junk.o
 Rem It is not clear what GCC version began supporting -mtune
 Rem and pentium4 on x86, so check this explicitly.
 echo main(){} >junk.c
-echo gcc -c -O2 -mtune=pentium4 junk.c >>config.log
-gcc -c -O2 -mtune=pentium4 junk.c >>config.log 2>&1
+echo %gccbin% -c -O2 -mtune=pentium4 junk.c >>config.log
+%gccbin% -c -O2 -mtune=pentium4 junk.c >>config.log 2>&1
 if not errorlevel 1 goto gccMtuneOk
 echo The failed program was: >>config.log
 type junk.c >>config.log
@@ -488,8 +497,8 @@ rm -f junk.c junk.o
 :gccdebug
 rem Check for DWARF-2 debug info support, else default to stabs
 echo main(){} >junk.c
-echo gcc -c -gdwarf-2 -g3 junk.c >>config.log
-gcc -c -gdwarf-2 -g3 junk.c >>config.log 2>&1
+echo %gccbin% -c -gdwarf-2 -g3 junk.c >>config.log
+%gccbin% -c -gdwarf-2 -g3 junk.c >>config.log 2>&1
 if not errorlevel 1 goto gccdwarf
 echo The failed program was: >>config.log
 type junk.c >>config.log
-- 
1.7.7.rc0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 0002-NT-build-ensure-GNU-make-makefiles-don-t-have-CRLF-l.patch --]
[-- Type: text/x-diff, Size: 28814 bytes --]

From 4f6735c28b423556e61e9af85f9683aa384d8237 Mon Sep 17 00:00:00 2001
From: Hannu Koivisto <azure@iki.fi>
Date: Sun, 28 Aug 2011 23:00:00 +0300
Subject: [PATCH 2/4] NT build: ensure GNU make makefiles don't have CRLF line
 ends

---
 nt/configure.bat   |    2 +
 nt/makefile.w32-in |  902 ++++++++++++++++++++++++++--------------------------
 2 files changed, 451 insertions(+), 453 deletions(-)

diff --git a/nt/configure.bat b/nt/configure.bat
index 9db688f..db57661 100755
--- a/nt/configure.bat
+++ b/nt/configure.bat
@@ -774,6 +774,8 @@ if "(%HAVE_RSVG%)" == "(1)" echo #define HAVE_RSVG 1 >>config.tmp
 
 echo /* End of settings from configure.bat.  */ >>config.tmp
 
+if %MAKECMD% == gmake dos2unix config.tmp config.settings
+
 Rem See if fc.exe returns a meaningful exit status.  If it does, we
 Rem might as well avoid unnecessary overwriting of config.h and epaths.h,
 Rem since this forces recompilation of every source file.
diff --git a/nt/makefile.w32-in b/nt/makefile.w32-in
index 31ca314..05ce4eb 100644
--- a/nt/makefile.w32-in
+++ b/nt/makefile.w32-in
@@ -1,453 +1,449 @@
-# -*- Makefile -*- for GNU Emacs on the Microsoft W32 API.
-# Copyright (C) 2000-2011 Free Software Foundation, Inc.
-#
-# Top level makefile for building GNU Emacs on Windows NT
-#
-# This file is part of GNU Emacs.
-
-# GNU Emacs is free software: you can redistribute it and/or modify
-# it under the terms of the GNU General Public License as published by
-# the Free Software Foundation, either version 3 of the License, or
-# (at your option) any later version.
-
-# GNU Emacs is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-
-# You should have received a copy of the GNU General Public License
-# along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.
-
-
-# FIXME: This file uses DOS EOLs.  Convert to Unix after 22.1 is out
-#        (and remove or replace this comment).
-
-VERSION		= 24.0.50
-
-TMP_DIST_DIR 	= emacs-$(VERSION)
-
-TRES		= $(BLD)/emacs.res
-CLIENTRES	= $(BLD)/emacsclient.res
-
-XMFLAGS		=
-
-ALL		= addpm ddeclient runemacs cmdproxy addsection preprep
-
-.PHONY: $(ALL)
-
-
-addpm:		  stamp_BLD $(BLD)/addpm.exe
-$(BLD)/addpm.exe: $(BLD)/addpm.$(O)
-		  $(LINK) $(LINK_OUT)$@ \
-		  $(LINK_FLAGS) $(ALL_DEPS) $(BASE_LIBS) $(ADVAPI32) \
-		  $(USER32) $(OLE32) $(UUID) $(SHELL32)
-
-ddeclient:	  stamp_BLD $(BLD)/ddeclient.exe
-$(BLD)/ddeclient.exe: $(BLD)/ddeclient.$(O)
-		  $(LINK) $(LINK_OUT)$@ \
-		  $(LINK_FLAGS) $(ALL_DEPS) $(BASE_LIBS) $(ADVAPI32) $(USER32)
-
-cmdproxy:	  stamp_BLD $(BLD)/cmdproxy.exe
-$(BLD)/cmdproxy.exe: $(BLD)/cmdproxy.$(O)
-		  $(LINK) $(LINK_OUT)$@ \
-		  $(LINK_FLAGS) $(ALL_DEPS) $(BASE_LIBS) $(USER32)
-
-addsection:	  stamp_BLD $(BLD)/addsection.exe
-$(BLD)/addsection.exe: $(BLD)/addsection.$(O)
-		  $(LINK) $(LINK_OUT)$@ \
-		  $(LINK_FLAGS) $(ALL_DEPS) $(BASE_LIBS) $(USER32)
-
-preprep:	  stamp_BLD $(BLD)/preprep.exe
-$(BLD)/preprep.exe: $(BLD)/preprep.$(O)
-		  $(LINK) $(LINK_OUT)$@ \
-		  $(LINK_FLAGS) $(ALL_DEPS) $(BASE_LIBS)
-
-#
-# The resource file.  NT 3.10 requires the use of cvtres; even though
-# it is not necessary on later versions, it is still ok to use it.
-#
-$(TRES):	emacs.rc icons/emacs.ico emacs.manifest stamp_BLD
-		$(RC) $(RC_OUT)$(TRES) emacs.rc
-
-$(CLIENTRES):	emacsclient.rc stamp_BLD
-		$(RC) $(RC_OUT)$(CLIENTRES) emacsclient.rc
-
-runemacs:	  stamp_BLD $(BLD)/runemacs.exe
-$(BLD)/runemacs.exe: $(BLD)/runemacs.$(O) $(TRES)
-		  $(LINK) $(LINK_OUT)$@ $(SUBSYSTEM_WINDOWS) \
-		  $(LINK_FLAGS) $(ALL_DEPS) $(BASE_LIBS) $(ADVAPI32) $(USER32)
-
-which-sh:
-	@echo Using $(THE_SHELL) as shell.
-
-# These depend on stamp_BLD to make sure the $(BLD) directory is created
-# before the compilation begins, even if Make runs several commands
-# in parallel under "make -j".
-#
-$(BLD)/addpm.$(O) $(BLD)/ddeclient.$(O) $(BLD)/runemacs.$(O) $(BLD)/cmdproxy.$(O) $(BLD)/addsection.$(O) $(BLD)/preprep.$(O): stamp_BLD
-
-#
-# Build emacs
-#
-all:	which-sh stamp_BLD $(ALL) $(CLIENTRES) maybe-bootstrap all-other-dirs-$(MAKETYPE)
-
-all-other-dirs-nmake: addsection
-	cd ..\lib
-	$(MAKE) $(MFLAGS) all
-	cd ..\lib-src
-	$(MAKE) $(MFLAGS) all
-	cd ..\src
-	$(MAKE) $(MFLAGS) all
-	cd ..\lisp
-	$(MAKE) $(MFLAGS) all
-	cd ..\leim
-	$(MAKE) $(MFLAGS) all
-	cd ..\nt
-
-all-other-dirs-gmake: addsection
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib all
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src all
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src all
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp all
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../leim all
-
-recompile:	recompile-$(MAKETYPE)
-
-recompile-nmake:
-	cd ..\lisp
-	$(MAKE) $(MFLAGS) recompile
-	cd ..\nt
-
-recompile-gmake:
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp recompile
-
-#### Bootstrapping.
-
-### This is meant for Emacs maintainers only.  It first cleans the
-### lisp subdirectory, removing all compiled Lisp files.  Then a
-### special emacs executable is built from Lisp sources, which is then
-### used to compile Lisp files.  The last step is a "normal" make.
-
-maybe-bootstrap: maybe-bootstrap-$(SHELLTYPE)
-
-# dummy target to force other targets to be evaluated.
-doit:
-
-maybe-bootstrap-CMD:	doit
-	@echo .
-	@if not EXIST ..\lisp\abbrev.elc echo Essential Lisp files seem to be missing.  You should either
-	@if not EXIST ..\lisp\abbrev.elc echo do 'make bootstrap' or create 'lisp/abbrev.elc' somehow
-	@echo .
-	@if not EXIST ..\lisp\abbrev.elc exit -1
-
-maybe-bootstrap-SH: doit
-	@if [ ! -f ../lisp/abbrev.elc ] ; then \
-	  echo; \
-	  echo "Essential Lisp files seem to be missing.  You should either"; \
-	  echo "do \`make bootstrap' or create \`lisp/abbrev.elc' somehow.";  \
-	  echo; \
-	  exit -1; \
-	fi
-
-# Bootstrap depends on cmdproxy because some Lisp functions
-# loaded during bootstrap may need to run shell commands.
-bootstrap:	addsection cmdproxy bootstrap-$(MAKETYPE)
-	$(MAKE) $(MFLAGS) $(XMFLAGS) all
-
-bootstrap-nmake: addsection cmdproxy
-	cd ..\lisp
-	$(MAKE) $(MFLAGS) bootstrap-clean
-	cd ..\src
-	$(MAKE) $(MFLAGS) clean
-	cd ..\lib-src
-	$(MAKE) $(MFLAGS) clean make-docfile
-	cd ..\lib
-	$(MAKE) $(MFLAGS) clean all
-	cd ..\src
-	$(MAKE) $(MFLAGS) bootstrap
-	$(MAKE) $(MFLAGS) bootstrap-clean
-	cd ..\nt
-	$(CP) $(BLD)/cmdproxy.exe ../bin
-	cd ..\lisp
-	$(MAKE) $(MFLAGS) SHELL=$(SHELLTYPE) bootstrap
-	cd ..\lib-src
-	$(MAKE) $(MFLAGS) DOC
-	cd ..\nt
-
-bootstrap-gmake: addsection cmdproxy
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp bootstrap-clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src clean make-docfile
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib clean all
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src bootstrap
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src bootstrap-clean
-	$(CP) $(BLD)/cmdproxy.exe ../bin
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp bootstrap
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src DOC
-
-bootstrap-clean: bootstrap-clean-$(MAKETYPE)
-
-bootstrap-clean-nmake:
-	cd ..\src
-	$(MAKE) $(MFLAGS) bootstrap-clean
-	cd ..\lib
-	$(MAKE) $(MFLAGS) clean
-	cd ..\lisp
-	$(MAKE) $(MFLAGS) bootstrap-clean
-
-bootstrap-clean-gmake:
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src bootstrap-clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp bootstrap-clean
-
-$(INSTALL_DIR):
-	- mkdir "$(INSTALL_DIR)"
-
-$(INSTALL_DIR)/bin: $(INSTALL_DIR)
-	- mkdir "$(INSTALL_DIR)/bin"
-
-#
-# Build and install emacs in INSTALL_DIR
-#
-.PHONY: install-bin install-shortcuts
-
-install: install-bin install-shortcuts
-
-install-bin: all $(INSTALL_DIR)/bin install-other-dirs-$(MAKETYPE)
-	- $(CP) $(BLD)/addpm.exe $(INSTALL_DIR)/bin
-	- $(CP) $(BLD)/ddeclient.exe $(INSTALL_DIR)/bin
-	- $(CP) $(BLD)/cmdproxy.exe $(INSTALL_DIR)/bin
-	- $(CP) $(BLD)/runemacs.exe $(INSTALL_DIR)/bin
-	- $(CP) README.W32 $(INSTALL_DIR)
-	- $(DEL) ../same-dir.tst
-	- $(DEL) $(INSTALL_DIR)/same-dir.tst
-	echo SameDirTest > "$(INSTALL_DIR)/same-dir.tst"
-	- mkdir "$(INSTALL_DIR)/etc"
-	- mkdir "$(INSTALL_DIR)/info"
-	- mkdir "$(INSTALL_DIR)/lock"
-	- mkdir "$(INSTALL_DIR)/data"
-	- mkdir "$(INSTALL_DIR)/site-lisp"
-	- mkdir "$(INSTALL_DIR)/etc/icons"
-	$(IFNOTSAMEDIR) $(CP) ../site-lisp/subdirs.el $(INSTALL_DIR)/site-lisp $(ENDIF)
-	$(IFNOTSAMEDIR) $(CP_DIR) ../etc $(INSTALL_DIR) $(ENDIF)
-	- $(CP_DIR) icons $(INSTALL_DIR)/etc
-	$(IFNOTSAMEDIR) $(CP_DIR) ../info $(INSTALL_DIR) $(ENDIF)
-	$(IFNOTSAMEDIR) $(CP) ../COPYING $(INSTALL_DIR) $(ENDIF)
-	- $(CP) ../COPYING $(INSTALL_DIR)/bin
-	- $(DEL) ../same-dir.tst
-	- $(DEL) $(INSTALL_DIR)/same-dir.tst
-
-install-other-dirs-nmake:
-	cd ..\lib-src
-	$(MAKE) $(MFLAGS) install
-	cd ..\src
-	$(MAKE) $(MFLAGS) install
-	cd ..\lisp
-	$(MAKE) $(MFLAGS) install
-	cd ..\leim
-	$(MAKE) $(MFLAGS) install
-	cd ..\nt
-
-install-other-dirs-gmake:
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src install
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src install
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp install
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../leim install
-
-install-shortcuts:
-	"$(INSTALL_DIR)/bin/addpm" -q
-
-dist: install-bin
-	mkdir $(TMP_DIST_DIR)
-	$(CP) "$(INSTALL_DIR)/BUGS" $(TMP_DIST_DIR)
-	$(CP) "$(INSTALL_DIR)/COPYING" $(TMP_DIST_DIR)
-	$(CP) "$(INSTALL_DIR)/README" $(TMP_DIST_DIR)
-	$(CP) "$(INSTALL_DIR)/README.W32" $(TMP_DIST_DIR)
-	$(CP) "$(INSTALL_DIR)/INSTALL" $(TMP_DIST_DIR)
-	$(CP_DIR) "$(INSTALL_DIR)/bin" $(TMP_DIST_DIR)
-	$(CP_DIR) "$(INSTALL_DIR)/etc" $(TMP_DIST_DIR)
-	$(CP_DIR) "$(INSTALL_DIR)/info" $(TMP_DIST_DIR)
-	$(CP_DIR) "$(INSTALL_DIR)/lisp" $(TMP_DIST_DIR)
-	$(CP_DIR) "$(INSTALL_DIR)/leim" $(TMP_DIST_DIR)
-	$(CP_DIR) "$(INSTALL_DIR)/site-lisp" $(TMP_DIST_DIR)
-	$(CP_DIR) $(DIST_FILES) $(TMP_DIST_DIR)/bin
-	$(COMSPEC)$(ComSpec) /c $(ARGQUOTE)zipdist.bat $(VERSION)$(ARGQUOTE)
-	$(DEL_TREE) $(TMP_DIST_DIR)
-
-force-info:
-# Note that doc/emacs/makefile knows how to
-# put the info files in $(infodir),
-# so we can do ok running make in the build dir.
-info: force-info info-$(MAKETYPE)
-
-info-nmake:
-	cd ..\doc\emacs
-	$(MAKE) $(MFLAGS) info
-	cd ..\misc
-	$(MAKE) $(MFLAGS) info
-	cd ..\lispref
-	$(MAKE) $(MFLAGS) info
-	cd ..\lispintro
-	$(MAKE) $(MFLAGS) info
-	cd $(MAKEDIR)
-
-info-gmake:
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/emacs info
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/misc info
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispref info
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispintro info
-#
-# Maintenance
-#
-clean:	clean-other-dirs-$(MAKETYPE)
-	- $(DEL) $(COMPILER_TEMP_FILES)
-	- $(DEL_TREE) $(OBJDIR)
-	- $(DEL) stamp_BLD
-	- $(DEL) ../etc/DOC ../etc/DOC-X
-
-clean-other-dirs-nmake:
-	cd ..\lib
-	$(MAKE) $(MFLAGS) clean
-	cd ..\lib-src
-	$(MAKE) $(MFLAGS) clean
-	cd ..\src
-	$(MAKE) $(MFLAGS) clean
-	cd ..\doc\lispintro
-	$(MAKE) $(MFLAGS) clean
-	cd ..\doc\lispref
-	$(MAKE) $(MFLAGS) clean
-	cd ..\leim
-	$(MAKE) $(MFLAGS) clean
-	cd ..\doc\emacs
-	$(MAKE) $(MFLAGS) clean
-	cd ..\doc\misc
-	$(MAKE) $(MFLAGS) clean
-	cd ..\nt
-
-clean-other-dirs-gmake:
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../leim clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/emacs clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/misc clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispintro clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispref clean
-
-cleanall-other-dirs-nmake:
-	cd ..\lib
-	$(MAKE) $(MFLAGS) cleanall
-	cd ..\lib-src
-	$(MAKE) $(MFLAGS) cleanall
-	cd ..\src
-	$(MAKE) $(MFLAGS) cleanall
-	cd ..\nt
-
-cleanall-other-dirs-gmake:
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib cleanall
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src cleanall
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src cleanall
-
-# We used to delete *~ here, but that might inadvertently remove
-# precious files if it happens to match their short 8+3 aliases.
-cleanall: clean cleanall-other-dirs-$(MAKETYPE)
-	 - $(DEL_TREE) obj
-	 - $(DEL_TREE) obj-spd
-	 - $(DEL_TREE) oo
-	 - $(DEL_TREE) oo-spd
-
-top-distclean:
-	- $(DEL) $(COMPILER_TEMP_FILES)
-	- $(DEL_TREE) obj
-	- $(DEL_TREE) obj-spd
-	- $(DEL_TREE) oo
-	- $(DEL_TREE) oo-spd
-	- $(DEL) stamp_BLD
-	- $(DEL) ../etc/DOC ../etc/DOC-X
-	- $(DEL) config.log Makefile
-	- $(DEL) ../README.W32
-
-distclean: distclean-other-dirs-$(MAKETYPE) top-distclean
-
-distclean-other-dirs-nmake:
-	cd ..\lib
-	$(MAKE) $(MFLAGS) distclean
-	cd ..\lib-src
-	$(MAKE) $(MFLAGS) distclean
-	cd ..\src
-	$(MAKE) $(MFLAGS) distclean
-	cd ..\lisp
-	$(MAKE) $(MFLAGS) distclean
-	cd ..\leim
-	$(MAKE) $(MFLAGS) distclean
-	cd ..\doc\emacs
-	$(MAKE) $(MFLAGS) distclean
-	cd ..\doc\misc
-	$(MAKE) $(MFLAGS) distclean
-	cd ..\doc\lispintro
-	$(MAKE) $(MFLAGS) distclean
-	cd ..\doc\lispref
-	$(MAKE) $(MFLAGS) distclean
-	cd ..\nt
-
-distclean-other-dirs-gmake:
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib distclean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src distclean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src distclean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp distclean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../leim distclean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/emacs distclean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/misc distclean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispintro distclean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispref distclean
-
-maintainer-clean: maintainer-clean-other-dirs-$(MAKETYPE) top-distclean
-
-maintainer-clean-other-dirs-nmake:
-	cd ..\lib
-	$(MAKE) $(MFLAGS) maintainer-clean
-	cd ..\lib-src
-	$(MAKE) $(MFLAGS) maintainer-clean
-	cd ..\src
-	$(MAKE) $(MFLAGS) maintainer-clean
-	cd ..\lisp
-	$(MAKE) $(MFLAGS) maintainer-clean
-	cd ..\leim
-	$(MAKE) $(MFLAGS) maintainer-clean
-	cd ..\doc\emacs
-	$(MAKE) $(MFLAGS) maintainer-clean
-	cd ..\doc\misc
-	$(MAKE) $(MFLAGS) maintainer-clean
-	cd ..\doc\lispintro
-	$(MAKE) $(MFLAGS) maintainer-clean
-	cd ..\doc\lispref
-	$(MAKE) $(MFLAGS) maintainer-clean
-	cd ..\nt
-
-maintainer-clean-other-dirs-gmake:
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib maintainer-clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src maintainer-clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src maintainer-clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp maintainer-clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../leim maintainer-clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/emacs maintainer-clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/misc maintainer-clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispintro maintainer-clean
-	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispref maintainer-clean
-
-realclean: cleanall
-	- $(DEL_TREE) ../bin
-
-TAGS: TAGS-$(MAKETYPE)
-
-frc:
-TAGS-gmake: frc
-	../lib-src/$(BLD)/etags $(CURDIR)/*.c
-	$(MAKE) $(MFLAGS) -C ../src TAGS TAGS-LISP
-	$(MAKE) $(MFLAGS) -C ../lib-src TAGS
-	$(MAKE) $(MFLAGS) -C ../lib TAGS
-
-TAGS-nmake:
-	echo This target is not supported with NMake
-
-.PHONY: frc
+# -*- Makefile -*- for GNU Emacs on the Microsoft W32 API.
+# Copyright (C) 2000-2011 Free Software Foundation, Inc.
+#
+# Top level makefile for building GNU Emacs on Windows NT
+#
+# This file is part of GNU Emacs.
+
+# GNU Emacs is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# GNU Emacs is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.
+
+VERSION		= 24.0.50
+
+TMP_DIST_DIR 	= emacs-$(VERSION)
+
+TRES		= $(BLD)/emacs.res
+CLIENTRES	= $(BLD)/emacsclient.res
+
+XMFLAGS		=
+
+ALL		= addpm ddeclient runemacs cmdproxy addsection preprep
+
+.PHONY: $(ALL)
+
+
+addpm:		  stamp_BLD $(BLD)/addpm.exe
+$(BLD)/addpm.exe: $(BLD)/addpm.$(O)
+		  $(LINK) $(LINK_OUT)$@ \
+		  $(LINK_FLAGS) $(ALL_DEPS) $(BASE_LIBS) $(ADVAPI32) \
+		  $(USER32) $(OLE32) $(UUID) $(SHELL32)
+
+ddeclient:	  stamp_BLD $(BLD)/ddeclient.exe
+$(BLD)/ddeclient.exe: $(BLD)/ddeclient.$(O)
+		  $(LINK) $(LINK_OUT)$@ \
+		  $(LINK_FLAGS) $(ALL_DEPS) $(BASE_LIBS) $(ADVAPI32) $(USER32)
+
+cmdproxy:	  stamp_BLD $(BLD)/cmdproxy.exe
+$(BLD)/cmdproxy.exe: $(BLD)/cmdproxy.$(O)
+		  $(LINK) $(LINK_OUT)$@ \
+		  $(LINK_FLAGS) $(ALL_DEPS) $(BASE_LIBS) $(USER32)
+
+addsection:	  stamp_BLD $(BLD)/addsection.exe
+$(BLD)/addsection.exe: $(BLD)/addsection.$(O)
+		  $(LINK) $(LINK_OUT)$@ \
+		  $(LINK_FLAGS) $(ALL_DEPS) $(BASE_LIBS) $(USER32)
+
+preprep:	  stamp_BLD $(BLD)/preprep.exe
+$(BLD)/preprep.exe: $(BLD)/preprep.$(O)
+		  $(LINK) $(LINK_OUT)$@ \
+		  $(LINK_FLAGS) $(ALL_DEPS) $(BASE_LIBS)
+
+#
+# The resource file.  NT 3.10 requires the use of cvtres; even though
+# it is not necessary on later versions, it is still ok to use it.
+#
+$(TRES):	emacs.rc icons/emacs.ico emacs.manifest stamp_BLD
+		$(RC) $(RC_OUT)$(TRES) emacs.rc || $(RC) $(RC_OUT)$(TRES) emacs22.rc
+
+$(CLIENTRES):	emacsclient.rc stamp_BLD
+		$(RC) $(RC_OUT)$(CLIENTRES) emacsclient.rc || $(RC) $(RC_OUT)$(CLIENTRES) emacsclient22.rc
+
+runemacs:	  stamp_BLD $(BLD)/runemacs.exe
+$(BLD)/runemacs.exe: $(BLD)/runemacs.$(O) $(TRES)
+		  $(LINK) $(LINK_OUT)$@ $(SUBSYSTEM_WINDOWS) \
+		  $(LINK_FLAGS) $(ALL_DEPS) $(BASE_LIBS) $(ADVAPI32) $(USER32)
+
+which-sh:
+	@echo Using $(THE_SHELL) as shell.
+
+# These depend on stamp_BLD to make sure the $(BLD) directory is created
+# before the compilation begins, even if Make runs several commands
+# in parallel under "make -j".
+#
+$(BLD)/addpm.$(O) $(BLD)/ddeclient.$(O) $(BLD)/runemacs.$(O) $(BLD)/cmdproxy.$(O) $(BLD)/addsection.$(O) $(BLD)/preprep.$(O): stamp_BLD
+
+#
+# Build emacs
+#
+all:	which-sh stamp_BLD $(ALL) $(CLIENTRES) maybe-bootstrap all-other-dirs-$(MAKETYPE)
+
+all-other-dirs-nmake: addsection
+	cd ..\lib
+	$(MAKE) $(MFLAGS) all
+	cd ..\lib-src
+	$(MAKE) $(MFLAGS) all
+	cd ..\src
+	$(MAKE) $(MFLAGS) all
+	cd ..\lisp
+	$(MAKE) $(MFLAGS) all
+	cd ..\leim
+	$(MAKE) $(MFLAGS) all
+	cd ..\nt
+
+all-other-dirs-gmake: addsection
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib all
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src all
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src all
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp all
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../leim all
+
+recompile:	recompile-$(MAKETYPE)
+
+recompile-nmake:
+	cd ..\lisp
+	$(MAKE) $(MFLAGS) recompile
+	cd ..\nt
+
+recompile-gmake:
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp recompile
+
+#### Bootstrapping.
+
+### This is meant for Emacs maintainers only.  It first cleans the
+### lisp subdirectory, removing all compiled Lisp files.  Then a
+### special emacs executable is built from Lisp sources, which is then
+### used to compile Lisp files.  The last step is a "normal" make.
+
+maybe-bootstrap: maybe-bootstrap-$(SHELLTYPE)
+
+# dummy target to force other targets to be evaluated.
+doit:
+
+maybe-bootstrap-CMD:	doit
+	@echo .
+	@if not EXIST ..\lisp\abbrev.elc echo Essential Lisp files seem to be missing.  You should either
+	@if not EXIST ..\lisp\abbrev.elc echo do 'make bootstrap' or create 'lisp/abbrev.elc' somehow
+	@echo .
+	@if not EXIST ..\lisp\abbrev.elc exit -1
+
+maybe-bootstrap-SH: doit
+	@if [ ! -f ../lisp/abbrev.elc ] ; then \
+	  echo; \
+	  echo "Essential Lisp files seem to be missing.  You should either"; \
+	  echo "do \`make bootstrap' or create \`lisp/abbrev.elc' somehow.";  \
+	  echo; \
+	  exit -1; \
+	fi
+
+# Bootstrap depends on cmdproxy because some Lisp functions
+# loaded during bootstrap may need to run shell commands.
+bootstrap:	addsection cmdproxy bootstrap-$(MAKETYPE)
+	$(MAKE) $(MFLAGS) $(XMFLAGS) all
+
+bootstrap-nmake: addsection cmdproxy
+	cd ..\lisp
+	$(MAKE) $(MFLAGS) bootstrap-clean
+	cd ..\src
+	$(MAKE) $(MFLAGS) clean
+	cd ..\lib-src
+	$(MAKE) $(MFLAGS) clean make-docfile
+	cd ..\lib
+	$(MAKE) $(MFLAGS) clean all
+	cd ..\src
+	$(MAKE) $(MFLAGS) bootstrap
+	$(MAKE) $(MFLAGS) bootstrap-clean
+	cd ..\nt
+	$(CP) $(BLD)/cmdproxy.exe ../bin
+	cd ..\lisp
+	$(MAKE) $(MFLAGS) SHELL=$(SHELLTYPE) bootstrap
+	cd ..\lib-src
+	$(MAKE) $(MFLAGS) DOC
+	cd ..\nt
+
+bootstrap-gmake: addsection cmdproxy
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp bootstrap-clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src clean make-docfile
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib clean all
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src bootstrap
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src bootstrap-clean
+	$(CP) $(BLD)/cmdproxy.exe ../bin
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp bootstrap
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src DOC
+
+bootstrap-clean: bootstrap-clean-$(MAKETYPE)
+
+bootstrap-clean-nmake:
+	cd ..\src
+	$(MAKE) $(MFLAGS) bootstrap-clean
+	cd ..\lib
+	$(MAKE) $(MFLAGS) clean
+	cd ..\lisp
+	$(MAKE) $(MFLAGS) bootstrap-clean
+
+bootstrap-clean-gmake:
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src bootstrap-clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp bootstrap-clean
+
+$(INSTALL_DIR):
+	- mkdir "$(INSTALL_DIR)"
+
+$(INSTALL_DIR)/bin: $(INSTALL_DIR)
+	- mkdir "$(INSTALL_DIR)/bin"
+
+#
+# Build and install emacs in INSTALL_DIR
+#
+.PHONY: install-bin install-shortcuts
+
+install: install-bin install-shortcuts
+
+install-bin: all $(INSTALL_DIR)/bin install-other-dirs-$(MAKETYPE)
+	- $(CP) $(BLD)/addpm.exe $(INSTALL_DIR)/bin
+	- $(CP) $(BLD)/ddeclient.exe $(INSTALL_DIR)/bin
+	- $(CP) $(BLD)/cmdproxy.exe $(INSTALL_DIR)/bin
+	- $(CP) $(BLD)/runemacs.exe $(INSTALL_DIR)/bin
+	- $(CP) README.W32 $(INSTALL_DIR)
+	- $(DEL) ../same-dir.tst
+	- $(DEL) $(INSTALL_DIR)/same-dir.tst
+	echo SameDirTest > "$(INSTALL_DIR)/same-dir.tst"
+	- mkdir "$(INSTALL_DIR)/etc"
+	- mkdir "$(INSTALL_DIR)/info"
+	- mkdir "$(INSTALL_DIR)/lock"
+	- mkdir "$(INSTALL_DIR)/data"
+	- mkdir "$(INSTALL_DIR)/site-lisp"
+	- mkdir "$(INSTALL_DIR)/etc/icons"
+	$(IFNOTSAMEDIR) $(CP) ../site-lisp/subdirs.el $(INSTALL_DIR)/site-lisp $(ENDIF)
+	$(IFNOTSAMEDIR) $(CP_DIR) ../etc $(INSTALL_DIR) $(ENDIF)
+	- $(CP_DIR) icons $(INSTALL_DIR)/etc
+	$(IFNOTSAMEDIR) $(CP_DIR) ../info $(INSTALL_DIR) $(ENDIF)
+	$(IFNOTSAMEDIR) $(CP) ../COPYING $(INSTALL_DIR) $(ENDIF)
+	- $(CP) ../COPYING $(INSTALL_DIR)/bin
+	- $(DEL) ../same-dir.tst
+	- $(DEL) $(INSTALL_DIR)/same-dir.tst
+
+install-other-dirs-nmake:
+	cd ..\lib-src
+	$(MAKE) $(MFLAGS) install
+	cd ..\src
+	$(MAKE) $(MFLAGS) install
+	cd ..\lisp
+	$(MAKE) $(MFLAGS) install
+	cd ..\leim
+	$(MAKE) $(MFLAGS) install
+	cd ..\nt
+
+install-other-dirs-gmake:
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src install
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src install
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp install
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../leim install
+
+install-shortcuts:
+	"$(INSTALL_DIR)/bin/addpm" -q
+
+dist: install-bin
+	mkdir $(TMP_DIST_DIR)
+	$(CP) "$(INSTALL_DIR)/BUGS" $(TMP_DIST_DIR)
+	$(CP) "$(INSTALL_DIR)/COPYING" $(TMP_DIST_DIR)
+	$(CP) "$(INSTALL_DIR)/README" $(TMP_DIST_DIR)
+	$(CP) "$(INSTALL_DIR)/README.W32" $(TMP_DIST_DIR)
+	$(CP) "$(INSTALL_DIR)/INSTALL" $(TMP_DIST_DIR)
+	$(CP_DIR) "$(INSTALL_DIR)/bin" $(TMP_DIST_DIR)
+	$(CP_DIR) "$(INSTALL_DIR)/etc" $(TMP_DIST_DIR)
+	$(CP_DIR) "$(INSTALL_DIR)/info" $(TMP_DIST_DIR)
+	$(CP_DIR) "$(INSTALL_DIR)/lisp" $(TMP_DIST_DIR)
+	$(CP_DIR) "$(INSTALL_DIR)/leim" $(TMP_DIST_DIR)
+	$(CP_DIR) "$(INSTALL_DIR)/site-lisp" $(TMP_DIST_DIR)
+	$(CP_DIR) $(DIST_FILES) $(TMP_DIST_DIR)/bin
+	$(COMSPEC)$(ComSpec) /c $(ARGQUOTE)zipdist.bat $(VERSION)$(ARGQUOTE)
+	$(DEL_TREE) $(TMP_DIST_DIR)
+
+force-info:
+# Note that doc/emacs/makefile knows how to
+# put the info files in $(infodir),
+# so we can do ok running make in the build dir.
+info: force-info info-$(MAKETYPE)
+
+info-nmake:
+	cd ..\doc\emacs
+	$(MAKE) $(MFLAGS) info
+	cd ..\misc
+	$(MAKE) $(MFLAGS) info
+	cd ..\lispref
+	$(MAKE) $(MFLAGS) info
+	cd ..\lispintro
+	$(MAKE) $(MFLAGS) info
+	cd $(MAKEDIR)
+
+info-gmake:
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/emacs info
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/misc info
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispref info
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispintro info
+#
+# Maintenance
+#
+clean:	clean-other-dirs-$(MAKETYPE)
+	- $(DEL) $(COMPILER_TEMP_FILES)
+	- $(DEL_TREE) $(OBJDIR)
+	- $(DEL) stamp_BLD
+	- $(DEL) ../etc/DOC ../etc/DOC-X
+
+clean-other-dirs-nmake:
+	cd ..\lib
+	$(MAKE) $(MFLAGS) clean
+	cd ..\lib-src
+	$(MAKE) $(MFLAGS) clean
+	cd ..\src
+	$(MAKE) $(MFLAGS) clean
+	cd ..\doc\lispintro
+	$(MAKE) $(MFLAGS) clean
+	cd ..\doc\lispref
+	$(MAKE) $(MFLAGS) clean
+	cd ..\leim
+	$(MAKE) $(MFLAGS) clean
+	cd ..\doc\emacs
+	$(MAKE) $(MFLAGS) clean
+	cd ..\doc\misc
+	$(MAKE) $(MFLAGS) clean
+	cd ..\nt
+
+clean-other-dirs-gmake:
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../leim clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/emacs clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/misc clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispintro clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispref clean
+
+cleanall-other-dirs-nmake:
+	cd ..\lib
+	$(MAKE) $(MFLAGS) cleanall
+	cd ..\lib-src
+	$(MAKE) $(MFLAGS) cleanall
+	cd ..\src
+	$(MAKE) $(MFLAGS) cleanall
+	cd ..\nt
+
+cleanall-other-dirs-gmake:
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib cleanall
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src cleanall
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src cleanall
+
+# We used to delete *~ here, but that might inadvertently remove
+# precious files if it happens to match their short 8+3 aliases.
+cleanall: clean cleanall-other-dirs-$(MAKETYPE)
+	 - $(DEL_TREE) obj
+	 - $(DEL_TREE) obj-spd
+	 - $(DEL_TREE) oo
+	 - $(DEL_TREE) oo-spd
+
+top-distclean:
+	- $(DEL) $(COMPILER_TEMP_FILES)
+	- $(DEL_TREE) obj
+	- $(DEL_TREE) obj-spd
+	- $(DEL_TREE) oo
+	- $(DEL_TREE) oo-spd
+	- $(DEL) stamp_BLD
+	- $(DEL) ../etc/DOC ../etc/DOC-X
+	- $(DEL) config.log Makefile
+	- $(DEL) ../README.W32
+
+distclean: distclean-other-dirs-$(MAKETYPE) top-distclean
+
+distclean-other-dirs-nmake:
+	cd ..\lib
+	$(MAKE) $(MFLAGS) distclean
+	cd ..\lib-src
+	$(MAKE) $(MFLAGS) distclean
+	cd ..\src
+	$(MAKE) $(MFLAGS) distclean
+	cd ..\lisp
+	$(MAKE) $(MFLAGS) distclean
+	cd ..\leim
+	$(MAKE) $(MFLAGS) distclean
+	cd ..\doc\emacs
+	$(MAKE) $(MFLAGS) distclean
+	cd ..\doc\misc
+	$(MAKE) $(MFLAGS) distclean
+	cd ..\doc\lispintro
+	$(MAKE) $(MFLAGS) distclean
+	cd ..\doc\lispref
+	$(MAKE) $(MFLAGS) distclean
+	cd ..\nt
+
+distclean-other-dirs-gmake:
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib distclean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src distclean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src distclean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp distclean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../leim distclean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/emacs distclean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/misc distclean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispintro distclean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispref distclean
+
+maintainer-clean: maintainer-clean-other-dirs-$(MAKETYPE) top-distclean
+
+maintainer-clean-other-dirs-nmake:
+	cd ..\lib
+	$(MAKE) $(MFLAGS) maintainer-clean
+	cd ..\lib-src
+	$(MAKE) $(MFLAGS) maintainer-clean
+	cd ..\src
+	$(MAKE) $(MFLAGS) maintainer-clean
+	cd ..\lisp
+	$(MAKE) $(MFLAGS) maintainer-clean
+	cd ..\leim
+	$(MAKE) $(MFLAGS) maintainer-clean
+	cd ..\doc\emacs
+	$(MAKE) $(MFLAGS) maintainer-clean
+	cd ..\doc\misc
+	$(MAKE) $(MFLAGS) maintainer-clean
+	cd ..\doc\lispintro
+	$(MAKE) $(MFLAGS) maintainer-clean
+	cd ..\doc\lispref
+	$(MAKE) $(MFLAGS) maintainer-clean
+	cd ..\nt
+
+maintainer-clean-other-dirs-gmake:
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib maintainer-clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lib-src maintainer-clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../src maintainer-clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp maintainer-clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../leim maintainer-clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/emacs maintainer-clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/misc maintainer-clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispintro maintainer-clean
+	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../doc/lispref maintainer-clean
+
+realclean: cleanall
+	- $(DEL_TREE) ../bin
+
+TAGS: TAGS-$(MAKETYPE)
+
+frc:
+TAGS-gmake: frc
+	../lib-src/$(BLD)/etags $(CURDIR)/*.c
+	$(MAKE) $(MFLAGS) -C ../src TAGS TAGS-LISP
+	$(MAKE) $(MFLAGS) -C ../lib-src TAGS
+	$(MAKE) $(MFLAGS) -C ../lib TAGS
+
+TAGS-nmake:
+	echo This target is not supported with NMake
+
+.PHONY: frc
-- 
1.7.7.rc0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: 0003-NT-build-fix-path-conflict-with-Cygwin-make-and-nati.patch --]
[-- Type: text/x-diff, Size: 3136 bytes --]

From 2345fc78ffb35a7669e47605ad298d71da94fa15 Mon Sep 17 00:00:00 2001
From: Hannu Koivisto <azure@iki.fi>
Date: Sun, 28 Aug 2011 23:00:00 +0300
Subject: [PATCH 3/4] NT build: fix path conflict with Cygwin make and native
 Emacs

Cygwin make doesn't like c:/foo/bar style paths at least in targets and
native Windows Emacs doesn't like Cygwin style /cygdrive/c/foo/bar paths.
Use relative paths to avoid the problem.
---
 leim/makefile.w32-in |    7 +++----
 lisp/makefile.w32-in |   10 ++++++----
 nt/gmake.defs        |   13 ++++---------
 3 files changed, 13 insertions(+), 17 deletions(-)

diff --git a/leim/makefile.w32-in b/leim/makefile.w32-in
index 2313843..736a49a 100644
--- a/leim/makefile.w32-in
+++ b/leim/makefile.w32-in
@@ -37,10 +37,9 @@ BUILT_EMACS = $(THISDIR)/$(dot)$(dot)/src/$(BLD)/emacs.exe
 buildlisppath=$(CURDIR)/$(dot)$(dot)/lisp
 
 # How to run Emacs.
-RUN_EMACS = "$(BUILT_EMACS)" -batch --no-site-file --no-site-lisp
-
-# Set EMACSLOADPATH correctly (already defined in environment).
-EMACSLOADPATH=$(buildlisppath)
+RUN_EMACS = "$(BUILT_EMACS)" -batch --no-site-file --no-site-lisp \
+            --eval $(ARGQUOTE)(push (expand-file-name $(DQUOTE)$(buildlisppath)$(DQUOTE)) load-path)$(ARGQUOTE)
+EMACSLOADPATH=
 
 # Subdirectories to be made if $(srcdir) is different from the current
 # directory.
diff --git a/lisp/makefile.w32-in b/lisp/makefile.w32-in
index c844a8f..4619776 100644
--- a/lisp/makefile.w32-in
+++ b/lisp/makefile.w32-in
@@ -33,7 +33,12 @@ EMACS = ../src/$(BLD)/emacs.exe
 
 # Command line flags for Emacs.
 
-EMACSOPT = -batch --no-site-file --no-site-lisp
+# Instead of using EMACSLOADPATH, which is cleared just in case, we'll rely
+# on expanded current directory set in EMACSOPT so that relative CURDIR can
+# be used.
+EMACSOPT = -batch --no-site-file --no-site-lisp \
+	   --eval $(ARGQUOTE)(push (expand-file-name $(DQUOTE).$(DQUOTE)) load-path)$(ARGQUOTE)
+EMACSLOADPATH=
 
 # Extra flags to pass to the byte compiler
 BYTE_COMPILE_EXTRA_FLAGS =
@@ -41,9 +46,6 @@ BYTE_COMPILE_EXTRA_FLAGS =
 # BYTE_COMPILE_EXTRA_FLAGS = --eval '(setq byte-compile-warnings (quote (not unresolved)))'
 # The example above is just for developers, it should not be used by default.
 
-# Set EMACSLOADPATH correctly (already defined in environment).
-EMACSLOADPATH=$(lisp)
-
 # Use C locale
 LC_ALL = C
 
diff --git a/nt/gmake.defs b/nt/gmake.defs
index bbb5602..2ceb216 100644
--- a/nt/gmake.defs
+++ b/nt/gmake.defs
@@ -77,15 +77,10 @@ endif
 
 MAKETYPE=gmake
 
-# The following "ifeq" does not appear to DTRT, and therefore breaks
-# the build on mingw32. Also the -m option does not exist in many
-# (reasonably recent even) versions of Cygwin. These issues need to be
-# remedied before putting this cygpath kludge back in.
-
-# Convert CURDIR to native file name, if in Cygwin format
-#ifeq "$(shell cygpath $(CURDIR))" "$(CURDIR)"
-#CURDIR	        := $(shell cygpath -m $(CURDIR))
-#endif
+# Use relative CURDIR to work around the conflict of Cygwin make
+# requiring /cygpath/c/.. style paths and native Windows Emacs not
+# understanding them.
+CURDIR=.
 
 THISDIR		= .
 
-- 
1.7.7.rc0


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: 0004-NT-build-install-target-fixes.patch --]
[-- Type: text/x-diff, Size: 7648 bytes --]

From 3383279d4141bea1bd8fca37bd6f6bfd0483487d Mon Sep 17 00:00:00 2001
From: Hannu Koivisto <azure@iki.fi>
Date: Sun, 28 Aug 2011 23:00:00 +0300
Subject: [PATCH 4/4] NT build: install target fixes

Support install directory with spaces in it.
Don't fail if target directories exist already.
---
 leim/makefile.w32-in    |   14 +++++++-------
 lib-src/makefile.w32-in |   18 +++++++++---------
 lisp/makefile.w32-in    |    6 +++---
 nt/gmake.defs           |    5 +++++
 nt/makefile.w32-in      |   40 ++++++++++++++++++++--------------------
 src/makefile.w32-in     |    4 ++--
 6 files changed, 46 insertions(+), 41 deletions(-)

diff --git a/leim/makefile.w32-in b/leim/makefile.w32-in
index 736a49a..60b9161 100644
--- a/leim/makefile.w32-in
+++ b/leim/makefile.w32-in
@@ -199,14 +199,14 @@ leim-list.el: $(SUBDIRS) $(WORLD) $(srcdir)/leim-ext.el
 	$(RUN_EMACS) --eval $(ARGQUOTE)(w32-append-code-lines $(DQUOTE)$@$(DQUOTE) $(DQUOTE)$(srcdir)/leim-ext.el$(DQUOTE))$(ARGQUOTE)
 
 install: all
-	- mkdir "$(INSTALLDIR)"
+	- mkdir -p "$(INSTALLDIR)"
 	- $(DEL) same-dir.tst
-	- $(DEL) $(INSTALL_DIR)/same-dir.tst
-	echo SameDirTest > $(INSTALL_DIR)/same-dir.tst
-	$(IFNOTSAMEDIR) $(CP) leim-list.el $(INSTALLDIR) $(ENDIF)
-	$(IFNOTSAMEDIR) $(CP_DIR) quail $(INSTALLDIR) $(ENDIF)
-	$(IFNOTSAMEDIR) $(CP_DIR) ja-dic $(INSTALLDIR) $(ENDIF)
-	- $(DEL) $(INSTALL_DIR)/same-dir.tst
+	- $(DEL) "$(INSTALL_DIR)/same-dir.tst"
+	echo SameDirTest > "$(INSTALL_DIR)/same-dir.tst"
+	$(IFNOTSAMEDIR) $(CP) leim-list.el "$(INSTALLDIR)" $(ENDIF)
+	$(IFNOTSAMEDIR) $(CP_DIR) quail "$(INSTALLDIR)" $(ENDIF)
+	$(IFNOTSAMEDIR) $(CP_DIR) ja-dic "$(INSTALLDIR)" $(ENDIF)
+	- $(DEL) "$(INSTALL_DIR)/same-dir.tst"
 
 clean mostlyclean:
 	- $(FOREACH) $(TIT) $(FORDO) $(DEL) $(FORVAR) $(ENDFOR)
diff --git a/lib-src/makefile.w32-in b/lib-src/makefile.w32-in
index 28f913a..1cc9634 100644
--- a/lib-src/makefile.w32-in
+++ b/lib-src/makefile.w32-in
@@ -304,15 +304,15 @@ all:		stamp_BLD $(ALL) $(DOC)
 #
 INSTALL_FILES = $(ALL)
 install:	$(INSTALL_FILES)
-		- mkdir "$(INSTALL_DIR)/bin"
-		$(CP) $(BLD)/etags.exe $(INSTALL_DIR)/bin
-		$(CP) $(BLD)/ebrowse.exe $(INSTALL_DIR)/bin
-		$(CP) $(BLD)/ctags.exe $(INSTALL_DIR)/bin
-		$(CP) $(BLD)/hexl.exe $(INSTALL_DIR)/bin
-		$(CP) $(BLD)/movemail.exe $(INSTALL_DIR)/bin
-		$(CP) $(BLD)/emacsclient.exe $(INSTALL_DIR)/bin
-		$(CP) $(BLD)/emacsclientw.exe $(INSTALL_DIR)/bin
-		- mkdir "$(INSTALL_DIR)/etc"
+		- mkdir -p "$(INSTALL_DIR)/bin"
+		$(CP) $(BLD)/etags.exe "$(INSTALL_DIR)/bin"
+		$(CP) $(BLD)/ebrowse.exe "$(INSTALL_DIR)/bin"
+		$(CP) $(BLD)/ctags.exe "$(INSTALL_DIR)/bin"
+		$(CP) $(BLD)/hexl.exe "$(INSTALL_DIR)/bin"
+		$(CP) $(BLD)/movemail.exe "$(INSTALL_DIR)/bin"
+		$(CP) $(BLD)/emacsclient.exe "$(INSTALL_DIR)/bin"
+		$(CP) $(BLD)/emacsclientw.exe "$(INSTALL_DIR)/bin"
+		- mkdir -p "$(INSTALL_DIR)/etc"
 		$(CP) $(DOC) $(INSTALL_DIR)/etc
 
 #
diff --git a/lisp/makefile.w32-in b/lisp/makefile.w32-in
index 4619776..7a292c6 100644
--- a/lisp/makefile.w32-in
+++ b/lisp/makefile.w32-in
@@ -508,7 +508,7 @@ bootstrap: update-subdirs autoloads mh-autoloads compile finder-data custom-deps
 # Windows 95 makes this harder than it should be.
 #
 install:
-		- mkdir "$(INSTALL_DIR)/lisp"
+		- mkdir -p "$(INSTALL_DIR)/lisp"
 		- $(DEL) ../same-dir.tst
 		- $(DEL) "$(INSTALL_DIR)/same-dir.tst"
 		echo SameDirTest > "$(INSTALL_DIR)/same-dir.tst"
@@ -534,13 +534,13 @@ install:
 # since cp does not preserve time stamps
 install-lisp-SH:
 	cp -f *.el "$(INSTALL_DIR)/lisp"
-	for dir in $(WINS); do [ -d "$(INSTALL_DIR)/lisp/$$dir" ] || mkdir "$(INSTALL_DIR)/lisp/$$dir"; done
+	for dir in $(WINS); do [ -d "$(INSTALL_DIR)/lisp/$$dir" ] || mkdir -p "$(INSTALL_DIR)/lisp/$$dir"; done
 	for dir in $(WINS); do cp -f $$dir/*.el "$(INSTALL_DIR)/lisp/$$dir"; done
 	for dir in . $(WINS); do cp $$dir/*.elc "$(INSTALL_DIR)/lisp/$$dir"; done
 
 install-lisp-CMD:
 	cp -f *.el "$(INSTALL_DIR)/lisp"
-	for %%f in ($(WINS)) do if not exist "$(INSTALL_DIR)/lisp/%%f" mkdir "$(INSTALL_DIR)/lisp/%%f"
+	for %%f in ($(WINS)) do if not exist "$(INSTALL_DIR)/lisp/%%f" mkdir -p "$(INSTALL_DIR)/lisp/%%f"
 	for %%f in ($(WINS)) do cp -f %%f/*.el "$(INSTALL_DIR)/lisp/%%f"
 	for %%f in (. $(WINS)) do cp -f %%f/*.elc "$(INSTALL_DIR)/lisp/%%f"
 
diff --git a/nt/gmake.defs b/nt/gmake.defs
index 2ceb216..74d1664 100644
--- a/nt/gmake.defs
+++ b/nt/gmake.defs
@@ -119,6 +119,11 @@ ifndef INSTALL_DIR
 INSTALL_DIR     = $(CURDIR)/..
 endif
 
+INSTALL_DIR_MIXED := $(INSTALL_DIR)
+ifeq "$(shell cygpath $(INSTALL_DIR))" "$(INSTALL_DIR)"
+INSTALL_DIR_MIXED := $(shell cygpath -m "$(INSTALL_DIR)")
+endif
+
 export EMACSLOADPATH
 
 # Determine the architecture we're running on.
diff --git a/nt/makefile.w32-in b/nt/makefile.w32-in
index 05ce4eb..c7cdf4a 100644
--- a/nt/makefile.w32-in
+++ b/nt/makefile.w32-in
@@ -197,10 +197,10 @@ bootstrap-clean-gmake:
 	$(MAKE) $(MFLAGS) $(XMFLAGS) -C ../lisp bootstrap-clean
 
 $(INSTALL_DIR):
-	- mkdir "$(INSTALL_DIR)"
+	- mkdir -p "$(INSTALL_DIR)"
 
 $(INSTALL_DIR)/bin: $(INSTALL_DIR)
-	- mkdir "$(INSTALL_DIR)/bin"
+	- mkdir -p "$(INSTALL_DIR)/bin"
 
 #
 # Build and install emacs in INSTALL_DIR
@@ -210,28 +210,28 @@ $(INSTALL_DIR)/bin: $(INSTALL_DIR)
 install: install-bin install-shortcuts
 
 install-bin: all $(INSTALL_DIR)/bin install-other-dirs-$(MAKETYPE)
-	- $(CP) $(BLD)/addpm.exe $(INSTALL_DIR)/bin
-	- $(CP) $(BLD)/ddeclient.exe $(INSTALL_DIR)/bin
-	- $(CP) $(BLD)/cmdproxy.exe $(INSTALL_DIR)/bin
-	- $(CP) $(BLD)/runemacs.exe $(INSTALL_DIR)/bin
-	- $(CP) README.W32 $(INSTALL_DIR)
+	- $(CP) $(BLD)/addpm.exe "$(INSTALL_DIR_MIXED)/bin"
+	- $(CP) $(BLD)/ddeclient.exe "$(INSTALL_DIR_MIXED)/bin"
+	- $(CP) $(BLD)/cmdproxy.exe "$(INSTALL_DIR_MIXED)/bin"
+	- $(CP) $(BLD)/runemacs.exe "$(INSTALL_DIR_MIXED)/bin"
+	- $(CP) README.W32 "$(INSTALL_DIR)"
 	- $(DEL) ../same-dir.tst
 	- $(DEL) $(INSTALL_DIR)/same-dir.tst
 	echo SameDirTest > "$(INSTALL_DIR)/same-dir.tst"
-	- mkdir "$(INSTALL_DIR)/etc"
-	- mkdir "$(INSTALL_DIR)/info"
-	- mkdir "$(INSTALL_DIR)/lock"
-	- mkdir "$(INSTALL_DIR)/data"
-	- mkdir "$(INSTALL_DIR)/site-lisp"
-	- mkdir "$(INSTALL_DIR)/etc/icons"
-	$(IFNOTSAMEDIR) $(CP) ../site-lisp/subdirs.el $(INSTALL_DIR)/site-lisp $(ENDIF)
-	$(IFNOTSAMEDIR) $(CP_DIR) ../etc $(INSTALL_DIR) $(ENDIF)
-	- $(CP_DIR) icons $(INSTALL_DIR)/etc
-	$(IFNOTSAMEDIR) $(CP_DIR) ../info $(INSTALL_DIR) $(ENDIF)
-	$(IFNOTSAMEDIR) $(CP) ../COPYING $(INSTALL_DIR) $(ENDIF)
-	- $(CP) ../COPYING $(INSTALL_DIR)/bin
+	- mkdir -p "$(INSTALL_DIR)/etc"
+	- mkdir -p "$(INSTALL_DIR)/info"
+	- mkdir -p "$(INSTALL_DIR)/lock"
+	- mkdir -p "$(INSTALL_DIR)/data"
+	- mkdir -p "$(INSTALL_DIR)/site-lisp"
+	- mkdir -p "$(INSTALL_DIR)/etc/icons"
+	$(IFNOTSAMEDIR) $(CP) ../site-lisp/subdirs.el "$(INSTALL_DIR)/site-lisp" $(ENDIF)
+	$(IFNOTSAMEDIR) $(CP_DIR) ../etc "$(INSTALL_DIR)" $(ENDIF)
+	- $(CP_DIR) icons "$(INSTALL_DIR)/etc"
+	$(IFNOTSAMEDIR) $(CP_DIR) ../info "$(INSTALL_DIR)" $(ENDIF)
+	$(IFNOTSAMEDIR) $(CP) ../COPYING "$(INSTALL_DIR)" $(ENDIF)
+	- $(CP) ../COPYING "$(INSTALL_DIR)/bin"
 	- $(DEL) ../same-dir.tst
-	- $(DEL) $(INSTALL_DIR)/same-dir.tst
+	- $(DEL) "$(INSTALL_DIR)/same-dir.tst"
 
 install-other-dirs-nmake:
 	cd ..\lib-src
diff --git a/src/makefile.w32-in b/src/makefile.w32-in
index 53cb5f8..c46d57c 100644
--- a/src/makefile.w32-in
+++ b/src/makefile.w32-in
@@ -307,8 +307,8 @@ $(TLASTLIB):	$(BLD)/lastfile.$(O)
 # Assuming INSTALL_DIR is defined, build and install emacs in it.
 #
 install:        $(ALL)
-	- mkdir "$(INSTALL_DIR)/bin"
-	$(CP) $(EMACS) $(INSTALL_DIR)/bin
+	- mkdir -p "$(INSTALL_DIR)/bin"
+	$(CP) $(EMACS) "$(INSTALL_DIR)/bin"
 
 #
 # Maintenance
-- 
1.7.7.rc0

Re: A few Windows build fixes

[Eli Zaretskii]

> From: Hannu Koivisto <azure@iki.fi>
> Date: Mon, 29 Aug 2011 01:46:59 +0300
> 
> I wanted to build the latest bzr trunk version of Emacs for Windows
> but soon realized that the makefiles and the configure process have
> lots of problems.

Only if you use Cygwin tools.  With native (MinGW/GnuWin32) tools,
there are no known problems, AFAIK.

> I'm attaching four patches that fix enough of the problems that
> building and installing with a modern Cygwin

Thanks.

> +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
that doesn't require another non-standard utility (e.g., by setting
some Cygwin-specific environment variable that is ignored by
non-Cygwin programs), or else some alternative condition that will
only fire with Cygwin Make being used, please modify this to use
that.  Otherwise, some other trick will be needed to avoid the extra
requirement of having dos2unix on PATH.

> --- a/nt/makefile.w32-in
> +++ b/nt/makefile.w32-in

Is there some real change here, or did you only change EOL format?  If
the former, please show just the changes in content.

> Cygwin make doesn't like c:/foo/bar style paths at least in targets and
> native Windows Emacs doesn't like Cygwin style /cygdrive/c/foo/bar paths.
> Use relative paths to avoid the problem.

It's true that the Cygwin build of Make doesn't support c:/foo in
targets, but the Windows Makefiles never use such targets, except
through $(CURDIR), which should return a Cygwin style file name with
Cygwin Make.  So I don't really see a problem that needs to be solved
here.  Perhaps I'm missing something; please show the actual problems
you had with this part.

In any case, I'd like to find a solution for this problem that targets
Cygwin alone, if possible.  Sprinkling quotes in 2 different styles
all over the Makefiles is not my idea of fun, because the quoting
issue is very fragile on Windows to begin with, especially since we
try to support at least 3 or 4 different combinations of tools.

> +CURDIR=.

This will break "make -C", won't it?  Or at least make it fragile and
unreliable.

> -	- mkdir "$(INSTALLDIR)"
> +	- mkdir -p "$(INSTALLDIR)"

Please don't.  We don't want to rely on the assumption that `mkdir' is
a GNU mkdir.exe.  This command needs also to run when the shell is
cmd.exe, and its built-in `mkdir' doesn't support the -p switch (it
creates intermediate directories by default).

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.

> +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?

If both are needed, we will need a corresponding change in nmake.defs.

Thanks again for working on this.

Re: A few Windows build fixes

[Hannu Koivisto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Hannu Koivisto <azure@iki.fi>
>> Date: Mon, 29 Aug 2011 01:46:59 +0300
>> 
>> I wanted to build the latest bzr trunk version of Emacs for Windows
>> but soon realized that the makefiles and the configure process have
>> lots of problems.
>
> Only if you use Cygwin tools.  With native (MinGW/GnuWin32) tools,
> there are no known problems, AFAIK.

I haven't heard of GnuWin32; looks like something similar to msys,
which I feel is the "standard" set of tools to be used with mingw.

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.

>> +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.

>> --- a/nt/makefile.w32-in
>> +++ b/nt/makefile.w32-in
>
> Is there some real change here, or did you only change EOL format?  If
> the former, please show just the changes in content.

EOL format plus removal of FIXME comment (which should be shown
only if you disable showing whitespace differences in your diff
inspecting tool of choice).

>> Cygwin make doesn't like c:/foo/bar style paths at least in targets and
>> native Windows Emacs doesn't like Cygwin style /cygdrive/c/foo/bar paths.
>> Use relative paths to avoid the problem.
>
> It's true that the Cygwin build of Make doesn't support c:/foo in
> targets, but the Windows Makefiles never use such targets, except
> through $(CURDIR), which should return a Cygwin style file name with
> Cygwin Make.  So I don't really see a problem that needs to be solved
> here.  Perhaps I'm missing something; please show the actual problems
> you had with this part.

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.

> In any case, I'd like to find a solution for this problem that targets
> Cygwin alone, if possible.  Sprinkling quotes in 2 different styles
> all over the Makefiles is not my idea of fun, because the quoting
> issue is very fragile on Windows to begin with, especially since we
> try to support at least 3 or 4 different combinations of tools.

At first I used macros DQUOTE etc. but gave up after seeing that
normal double quotes were used in many, many places.

>> +CURDIR=.
>
> This will break "make -C", won't it?  Or at least make it fragile and
> unreliable.

Perhaps.  Is there a need to use -C when building Emacs for
Windows?  A more important need than to build Emacs under Cygwin?

>> -	- mkdir "$(INSTALLDIR)"
>> +	- mkdir -p "$(INSTALLDIR)"
>
> Please don't.  We don't want to rely on the assumption that `mkdir' is
> a GNU mkdir.exe.  This command needs also to run when the shell is
> cmd.exe, and its built-in `mkdir' doesn't support the -p switch (it
> creates intermediate directories by default).

Using cmd didn't work with mingw/msys (make SHELL=cmd.exe didn't do
anything at all) so I couldn't test that.  Not that I would have
considered supporting cmd as the shell (with GNU make makefiles,
nmake is another matter) even if it had worked.

> 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.

Well, if mkdir in cmd works like "mkdir -p", I suppose one could
simply use a macro and set it to either mkdir or mkdir -p depending
on the shell being used.

Not solving this means that "make install" won't work when cmd is
not used.

>> +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.  `cp' and
everything else is assumed to be a Cygwin version when building
under Cygwin.

> 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.

-- 
Hannu

Re: A few Windows build fixes

[Eli Zaretskii]

> From: Hannu Koivisto <azure@iki.fi>
> Date: Mon, 29 Aug 2011 11:18:33 +0300
> 
> >> I wanted to build the latest bzr trunk version of Emacs for Windows
> >> but soon realized that the makefiles and the configure process have
> >> lots of problems.
> >
> > Only if you use Cygwin tools.  With native (MinGW/GnuWin32) tools,
> > there are no known problems, AFAIK.
> 
> I haven't heard of GnuWin32; looks like something similar to msys,
> which I feel is the "standard" set of tools to be used with mingw.

No.  The sole purpose of the MSYS tools is to allow building MinGW
packages that require running Posix autotools, especially the
configure shell script, as part of the build.  Therefore, the MSYS
ports of GNU packages have a certain Posix layer built into them, and
they also have that filename-fixing code that caused you (and others)
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.

> 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.

> >> +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?

> >> Cygwin make doesn't like c:/foo/bar style paths at least in targets and
> >> native Windows Emacs doesn't like Cygwin style /cygdrive/c/foo/bar paths.
> >> Use relative paths to avoid the problem.
> >
> > It's true that the Cygwin build of Make doesn't support c:/foo in
> > targets, but the Windows Makefiles never use such targets, except
> > through $(CURDIR), which should return a Cygwin style file name with
> > Cygwin Make.  So I don't really see a problem that needs to be solved
> > here.  Perhaps I'm missing something; please show the actual problems
> > you had with this part.
> 
> 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?
Would that solve the problem?  How about using `cygpath' to convert
the file names when Cygwin tools are used?

> >> +CURDIR=.
> >
> > This will break "make -C", won't it?  Or at least make it fragile and
> > unreliable.
> 
> Perhaps.  Is there a need to use -C when building Emacs for
> Windows?

Yes, definitely: using -C is more portable than using "cd", because
the latter has shell-specific issues (style of slashes, for example),
and the Windows Makefiles need to support at least sh.exe and cmd.exe.
We already use "make -C" quite a lot, as you can see.

> A more important need than to build Emacs under Cygwin?

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.

> 
> >> -	- mkdir "$(INSTALLDIR)"
> >> +	- mkdir -p "$(INSTALLDIR)"
> >
> > Please don't.  We don't want to rely on the assumption that `mkdir' is
> > a GNU mkdir.exe.  This command needs also to run when the shell is
> > cmd.exe, and its built-in `mkdir' doesn't support the -p switch (it
> > creates intermediate directories by default).
> 
> Using cmd didn't work with mingw/msys (make SHELL=cmd.exe didn't do
> anything at all)

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
will cause Make to use cmd.exe.  "make SHELL=cmd.exe" should also work
with that port of GNU Make.

> Not that I would have considered supporting cmd as the shell (with
> GNU make makefiles, nmake is another matter) even if it had worked.

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.

> > 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.
> 
> Well, if mkdir in cmd works like "mkdir -p", I suppose one could
> simply use a macro and set it to either mkdir or mkdir -p depending
> on the shell being used.

Fine with me.

> Not solving this means that "make install" won't work when cmd is
> not used.

It will work if INSTALL_DIR already exists.

> >> +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?

If not, is it possible to define a macro that on Cygwin will run the
file name through `cygpath'?

> > 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.

Re: A few Windows build fixes

[Hannu Koivisto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Hannu Koivisto <azure@iki.fi>
>> 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

Re: A few Windows build fixes

[Eli Zaretskii]

> From: Hannu Koivisto <azure@iki.fi>
> Date: Mon, 29 Aug 2011 15:03:07 +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.

You are not required to test them yourself, sorry if I was unclear
about that.  The only requirement is to not use anything that is
guaranteed to break the other environments.  Any other issues that are
not immediately clear by just reading the diffs will be in due time
discovered by others, who do have those tools installed, and we can
deal with them at that time.

> 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.

Hmm... this actually gives me an idea.  How about providing a
completely separate set of Makefile.cygwin-in files, whose sole target
will be the native build with Cygwin tools?  Then the only changes
that need to be aware of the other Windows builds will be in
nt/configure.bat.

Of course, the downside of this would be the need to maintain a
separate set of Makefiles, although we could factor out at least the
dependencies to make it less painful...  Hmm...  Alternatively, would
it be possible to have just a separate nt/cygwin.defs file, to be used
instead of gmake.defs, and fix any issues specific to Cygwin, like
/cygdrive etc., in that file?

> > 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.

You are probably right, I will add this to my TODO.

> >> 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.

Actually, it does, because each mkdir command is invoked with the `-'
flag before it. ;-) 

> 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.

The MSVC build indeed needs some care, I think no one has tried to use
it for a long time.  You will probably find the patch and the
discussions in these 2 threads useful:

 http://lists.gnu.org/archive/html/emacs-devel/2010-12/msg00408.html
 http://lists.gnu.org/archive/html/emacs-devel/2011-01/msg00108.html

I still have on my TODO to apply those patches after some changes, as
discussed on the list, but if you can do that as part of your work,
and also update the patch wrt the latest trunk while at that, it would
be much better, as I don't really use MSVC myself (and none of the
other contributors to the w32 port does, AFAIK).

Thanks.

Re: A few Windows build fixes

[Stefan Monnier]

> Hmm... this actually gives me an idea.  How about providing a
> completely separate set of Makefile.cygwin-in files, whose sole target
> will be the native build with Cygwin tools?  Then the only changes
> that need to be aware of the other Windows builds will be in
> nt/configure.bat.

Here's another idea:
- make the normal configure.in work to build the native build using
  cygwin tools.
- remove the sh.exe support in the makefile.w32-in (as you said, good
  sh.exe is rare under Windows and if the user could use the standard
  autoconf stuff with cygwin if she wants to use a real POSIX sh).


        Stefan

Re: A few Windows build fixes

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Hannu Koivisto <azure@iki.fi>, emacs-devel@gnu.org
> Date: Mon, 29 Aug 2011 11:55:52 -0400
> 
> - make the normal configure.in work to build the native build using
>   cygwin tools.

That would be ideal for Cygwin users, but it's a much larger job,
AFAICS.  Volunteers are welcome, as always.

Re: A few Windows build fixes

[Stefan Monnier]

>> It's true that the Cygwin build of Make doesn't support c:/foo in
>> targets, but the Windows Makefiles never use such targets, except
>> through $(CURDIR), which should return a Cygwin style file name with
>> Cygwin Make.  So I don't really see a problem that needs to be solved
>> here.  Perhaps I'm missing something; please show the actual problems
>> you had with this part.
> 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.

There's a general need for Emacs to understand/accept /cygdrive/foo
names passed on the command-line, so that could be fixed in
lisp/startup.el and lisp/w32*.el.


        Stefan

Re: A few Windows build fixes

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 29 Aug 2011 11:48:32 -0400
> Cc: emacs-devel@gnu.org
> 
> > 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.
> 
> There's a general need for Emacs to understand/accept /cygdrive/foo
> names passed on the command-line, so that could be fixed in
> lisp/startup.el and lisp/w32*.el.

That would fix the invocations of Emacs, but I suspect there are also
invocations of other programs, like addpm and etags, which will suffer
from the same problem and cannot be fixed like that without
non-trivial source-level changes.  Also, there's a problem when the
same CURDIR-based file name is passed to `cp' or `rm', which are
Cygwin programs and therefore need the original /cygdrive/x/foo file
name, and also to a non-Cygwin program like addpm.  It's a mess...

Re: A few Windows build fixes

[Jan Djärv]

Eli Zaretskii skrev 2011-08-29 18:08:
>> From: Stefan Monnier<monnier@iro.umontreal.ca>
>> Date: Mon, 29 Aug 2011 11:48:32 -0400
>> Cc: emacs-devel@gnu.org
>>
>>> 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.
>>
>> There's a general need for Emacs to understand/accept /cygdrive/foo
>> names passed on the command-line, so that could be fixed in
>> lisp/startup.el and lisp/w32*.el.
>
> That would fix the invocations of Emacs, but I suspect there are also
> invocations of other programs, like addpm and etags, which will suffer
> from the same problem and cannot be fixed like that without
> non-trivial source-level changes.  Also, there's a problem when the
> same CURDIR-based file name is passed to `cp' or `rm', which are
> Cygwin programs and therefore need the original /cygdrive/x/foo file
> name, and also to a non-Cygwin program like addpm.  It's a mess...

Cygwin programs do understand that x:/foo is the same as /cygdrive/x/foo.
Programs output a warning the first time, but you can disable the warning.

	Jan D.

Re: A few Windows build fixes

[Vijay Lakshminarayanan]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> It's true that the Cygwin build of Make doesn't support c:/foo in
>>> targets, but the Windows Makefiles never use such targets, except
>>> through $(CURDIR), which should return a Cygwin style file name with
>>> Cygwin Make.  So I don't really see a problem that needs to be solved
>>> here.  Perhaps I'm missing something; please show the actual problems
>>> you had with this part.
>> 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.
>
> There's a general need for Emacs to understand/accept /cygdrive/foo
> names passed on the command-line, so that could be fixed in
> lisp/startup.el and lisp/w32*.el.

There's cygwin-mount.el available as an elpa package in one of
http://tromey.com/elpa or http://marmalade-repo.org/packages/ which
works in most cases.

>         Stefan
>

-- 
Cheers
~vijay

Gnus should be more complicated.

Re: A few Windows build fixes

[Eli Zaretskii]

> From: Vijay Lakshminarayanan <laksvij@gmail.com>
> Date: Wed, 31 Aug 2011 08:12:53 +0530
> Cc: Hannu Koivisto <azure@iki.fi>, emacs-devel@gnu.org
> 
> > There's a general need for Emacs to understand/accept /cygdrive/foo
> > names passed on the command-line, so that could be fixed in
> > lisp/startup.el and lisp/w32*.el.
> 
> There's cygwin-mount.el available as an elpa package in one of
> http://tromey.com/elpa or http://marmalade-repo.org/packages/ which
> works in most cases.

This has come up before (search the archives): cygwin-mount.el alone
is not enough to solve this problem reliably.

Re: A few Windows build fixes

[Stefan Monnier]

>> > There's a general need for Emacs to understand/accept /cygdrive/foo
>> > names passed on the command-line, so that could be fixed in
>> > lisp/startup.el and lisp/w32*.el.
>> There's cygwin-mount.el available as an elpa package in one of
>> http://tromey.com/elpa or http://marmalade-repo.org/packages/ which
>> works in most cases.

cygwin-mount.el is a good package, but it has at least the following
problems:
- it affects all file-name operations within Emacs.  That's good if you
  (the user) want to pretend that Emacs understands cygwin names and
  want to be able to type them in, perform completion and stuff.  But it
  is too intrusive otherwise.
- it can bump into ambiguities ("/home" can mean the "home" subdir in
  cygwin's root directory, or it can mean C:/home).  This is not
  cygwin-mount's fault, but because of how it works, it doesn't try to
  solve those ambiguities too carefully.

So what I proposed above is to use something that also understands
cygwin file names, but only at those places in the code where it's
likely to appear (i.e. for file names that come from outside Emacs), at
which point we can more easily try and resolve ambiguities and we're less
likely to introduce problems.


        Stefan

Re: A few Windows build fixes

[Vijay Lakshminarayanan]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> > There's a general need for Emacs to understand/accept /cygdrive/foo
>>> > names passed on the command-line, so that could be fixed in
>>> > lisp/startup.el and lisp/w32*.el.
>>> There's cygwin-mount.el available as an elpa package in one of
>>> http://tromey.com/elpa or http://marmalade-repo.org/packages/ which
>>> works in most cases.
>
> cygwin-mount.el is a good package, but it has at least the following
> problems:
> - it affects all file-name operations within Emacs.  That's good if you
>   (the user) want to pretend that Emacs understands cygwin names and
>   want to be able to type them in, perform completion and stuff.  But it
>   is too intrusive otherwise.
> - it can bump into ambiguities ("/home" can mean the "home" subdir in
>   cygwin's root directory, or it can mean C:/home).  This is not
>   cygwin-mount's fault, but because of how it works, it doesn't try to
>   solve those ambiguities too carefully.
>
> So what I proposed above is to use something that also understands
> cygwin file names, but only at those places in the code where it's
> likely to appear (i.e. for file names that come from outside Emacs), at
> which point we can more easily try and resolve ambiguities and we're less
> likely to introduce problems.

Going through w32-fns.el, I see there's `w32-convert-standard-filename'
which actually replaces /cygdrive/ paths correctly.  Indeed, 

(convert-standard-filename
 "/cygdrive/c/programs/emacs-24.0.50/lisp/w32-fns.el")

; => "c:\\programs\\emacs-24.0.50\\lisp\\w32-fns.el"

does the right thing.

I briefly went thru `find-file' and it doesn't use
`convert-standard-filename' but that's probably the wrong place to
change anyway.

I made the following change to `server-visit-files'

$ diff -u server.el~ server.el
--- server.el~  2011-06-20 12:26:32.000000000 +0530
+++ server.el   2011-09-01 22:31:53.195000000 +0530
@@ -1182,6 +1182,7 @@
        (let* ((minibuffer-auto-raise (or server-raise-frame
                                          minibuffer-auto-raise))
               (filen (car file))
+              (filen (convert-standard-filename filen))
               (obuf (get-file-buffer filen)))
          (add-to-history 'file-name-history filen)
          (if (null obuf)

and then tried

$ emacsclient -n /cygdrive/c/autoexec.bat

but it didn't work because emacsclient provides emacs with the path
"c:/cygdrive/c/autoexec.bat".  The code should be a little better and
check if the file exists (if yes, open immediately) else check if it's a
cygwin provided path (have defvars that check if (1) we're on windows
and (2) is it a cygwin path...).  (Checking if cygwin is in PATH won't
work because it's possible that emacs is in cygwin's path but not vice
versa.)

Is this the right way to go about things?

>         Stefan

-- 
Cheers
~vijay

Gnus should be more complicated.

Re: A few Windows build fixes

[Andy Moreton]

On Thu 01 Sep 2011, Vijay Lakshminarayanan wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> cygwin-mount.el is a good package, but it has at least the following
>> problems:
>> - it affects all file-name operations within Emacs.  That's good if you
>>   (the user) want to pretend that Emacs understands cygwin names and
>>   want to be able to type them in, perform completion and stuff.  But it
>>   is too intrusive otherwise.
>> - it can bump into ambiguities ("/home" can mean the "home" subdir in
>>   cygwin's root directory, or it can mean C:/home).  This is not
>>   cygwin-mount's fault, but because of how it works, it doesn't try to
>>   solve those ambiguities too carefully.
>>
>> So what I proposed above is to use something that also understands
>> cygwin file names, but only at those places in the code where it's
>> likely to appear (i.e. for file names that come from outside Emacs), at
>> which point we can more easily try and resolve ambiguities and we're less
>> likely to introduce problems.
>
> Going through w32-fns.el, I see there's `w32-convert-standard-filename'
> which actually replaces /cygdrive/ paths correctly.  Indeed, 
>
> (convert-standard-filename
>  "/cygdrive/c/programs/emacs-24.0.50/lisp/w32-fns.el")
>
> ; => "c:\\programs\\emacs-24.0.50\\lisp\\w32-fns.el"
>
> does the right thing.

This is buggy. The '/cygdrive' prefix can be replaced per-user or system
wide - see the cygwin mount(1) manpage for details.

    AndyM

Re: A few Windows build fixes

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Fri, 02 Sep 2011 01:14:02 +0100
> 
> > (convert-standard-filename
> >  "/cygdrive/c/programs/emacs-24.0.50/lisp/w32-fns.el")
> >
> > ; => "c:\\programs\\emacs-24.0.50\\lisp\\w32-fns.el"
> >
> > does the right thing.
> 
> This is buggy. The '/cygdrive' prefix can be replaced per-user or system
> wide - see the cygwin mount(1) manpage for details.

Full support for Cygwin-specific file names can only happen on the C
level.  E.g., in w32.c:normalize_filename.  We should probably have a
similar function in ntlib, because lib-src programs will need to use
it as well (see the example with emacsclient posted here).

Anything else will necessarily be buggy or at least incomplete.

And even on the C level, this should be a user option, because
otherwise users who don't have Cygwin anywhere in sight will be unable
to have a real `x:/cygdrive' directory on each of their logical disks.

Re: A few Windows build fixes

[Andy Moreton]

On Fri 02 Sep 2011, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton@gmail.com>
>> Date: Fri, 02 Sep 2011 01:14:02 +0100
>> 
>> > (convert-standard-filename
>> >  "/cygdrive/c/programs/emacs-24.0.50/lisp/w32-fns.el")
>> >
>> > ; => "c:\\programs\\emacs-24.0.50\\lisp\\w32-fns.el"
>> >
>> > does the right thing.
>> 
>> This is buggy. The '/cygdrive' prefix can be replaced per-user or system
>> wide - see the cygwin mount(1) manpage for details.
>
> Full support for Cygwin-specific file names can only happen on the C
> level.  E.g., in w32.c:normalize_filename.  We should probably have a
> similar function in ntlib, because lib-src programs will need to use
> it as well (see the example with emacsclient posted here).
>
> Anything else will necessarily be buggy or at least incomplete.

I disagree. The right way to get the cygwin mount points is to run
'mount -m' and look at the output. Doing so at the C level properly
involves calling into the cygwin DLL, which is fragile for a non-cygwin
application.

> And even on the C level, this should be a user option, because
> otherwise users who don't have Cygwin anywhere in sight will be unable
> to have a real `x:/cygdrive' directory on each of their logical disks.

Agreed.

While cygwin-mount.el is too intrusive, its approach of running mount is
correct. Perhaps a conmbination of the mount table from cygwin-mount.el
integrated with some tramp support would do it ?

    AndyM

Re: A few Windows build fixes

[Stefan Monnier]

>> Full support for Cygwin-specific file names can only happen on the C
>> level.  E.g., in w32.c:normalize_filename.  We should probably have a
[...]
> I disagree. The right way to get the cygwin mount points is to run
> 'mount -m' and look at the output. Doing so at the C level properly
> involves calling into the cygwin DLL, which is fragile for a non-cygwin
> application.

That's also my impression.  The way cywin-mount.el does it seems good enough.

>> similar function in ntlib, because lib-src programs will need to use
>> it as well (see the example with emacsclient posted here).

I don't think so.  E.g. emacsclient doesn't need to know about those
things, because it should just pass its arguments untouched to server.el
which can then do whatever it feels like doing with it, including
un-cygwinize file names.

> While cygwin-mount.el is too intrusive, its approach of running mount is
> correct. Perhaps a conmbination of the mount table from cygwin-mount.el
> integrated with some tramp support would do it ?

No, the whole point of my discussion is that it should *not* be
a file-name-handler (i.e. unlike Tramp and cygwin-mount) because that's
too intrusive.  If you want cygwin-name support within Emacs (i.e. as
a file-name-handler), then cygwin-mount is the right way to do it.


        Stefan

Re: A few Windows build fixes

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 02 Sep 2011 08:48:27 -0400
> Cc: emacs-devel@gnu.org
> 
> >> similar function in ntlib, because lib-src programs will need to use
> >> it as well (see the example with emacsclient posted here).
> 
> I don't think so.  E.g. emacsclient doesn't need to know about those
> things, because it should just pass its arguments untouched to server.el
> which can then do whatever it feels like doing with it, including
> un-cygwinize file names.

emacsclient already leaves alone any file name that begins with a
slash, so the observation that it does something with /cygdrive/x/foo
file names needs more info to understand why that happens.

But in general, it is my experience that if several programs pass file
names between them, any "magic" file names should be handled in the
same way by all of them.  Otherwise, the solution will never be
reliable enough.

Re: A few Windows build fixes

[Jason Rumney]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I don't think so.  E.g. emacsclient doesn't need to know about those
> things, because it should just pass its arguments untouched to server.el
> which can then do whatever it feels like doing with it, including
> un-cygwinize file names.

emacsclient needs to convert relative file names to absolute file
names.

Re: A few Windows build fixes

[Stefan Monnier]

>> I don't think so.  E.g. emacsclient doesn't need to know about those
>> things, because it should just pass its arguments untouched to server.el
>> which can then do whatever it feels like doing with it, including
>> un-cygwinize file names.
> emacsclient needs to convert relative file names to absolute file
> names.

No.  It needs to pass the PWD to server.el instead (which can then do
this conversion if/when needed).  The intelligence should be on the
server.el side.


        Stefan

Re: A few Windows build fixes

[Eli Zaretskii]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Fri, 02 Sep 2011 12:43:03 +0100
> 
> > Full support for Cygwin-specific file names can only happen on the C
> > level.  E.g., in w32.c:normalize_filename.  We should probably have a
> > similar function in ntlib, because lib-src programs will need to use
> > it as well (see the example with emacsclient posted here).
> >
> > Anything else will necessarily be buggy or at least incomplete.
> 
> I disagree. The right way to get the cygwin mount points is to run
> 'mount -m' and look at the output. Doing so at the C level properly
> involves calling into the cygwin DLL, which is fragile for a non-cygwin
> application.

It doesn't matter who and how runs "mount -m".  The results of that
should be used on the C level.  Otherwise, the result will be
semi-broken, because Emacs manipulates file names on the C level
without going through Lisp.

Re: A few Windows build fixes

[Stefan Monnier]

> It doesn't matter who and how runs "mount -m".  The results of that
> should be used on the C level.  Otherwise, the result will be

I don't think so: we only want to convert cygwin file names when they
"enter" Emacs and everything else (e.g. all primitives that access
files) should not know about them.


        Stefan

Re: A few Windows build fixes

[Vijay Lakshminarayanan]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> It doesn't matter who and how runs "mount -m".  The results of that
>> should be used on the C level.  Otherwise, the result will be
>
> I don't think so: we only want to convert cygwin file names when they
> "enter" Emacs and everything else (e.g. all primitives that access
> files) should not know about them.

I think you're both missing one crucial point: it is possible that
cygwin is installed and Emacs doesn't know of this and has no way to
know (because /usr/bin aka c:\cygwin\bin isn't in Emacs's path).

Of course, any future implementation could condition itself to support
cygwin paths iff cygwin's mount is accessible via (getenv "PATH").

>         Stefan
>

-- 
Cheers
~vijay

Gnus should be more complicated.

Re: A few Windows build fixes

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org
> Date: Fri, 02 Sep 2011 10:48:42 -0400
> 
> > It doesn't matter who and how runs "mount -m".  The results of that
> > should be used on the C level.  Otherwise, the result will be
> 
> I don't think so: we only want to convert cygwin file names when they
> "enter" Emacs and everything else (e.g. all primitives that access
> files) should not know about them.

You cannot possibly hope to plug all the holes this way.  A file name
can "enter" Emacs in any number of ways, including as a substring of
some string or buffer.  Trying to catch all those loopholes is never
going to work reliably.

Re: A few Windows build fixes

[Stefan Monnier]

>> > It doesn't matter who and how runs "mount -m".  The results of that
>> > should be used on the C level.  Otherwise, the result will be
>> I don't think so: we only want to convert cygwin file names when they
>> "enter" Emacs and everything else (e.g. all primitives that access
>> files) should not know about them.
> You cannot possibly hope to plug all the holes this way.  A file name
> can "enter" Emacs in any number of ways, including as a substring of
> some string or buffer.  Trying to catch all those loopholes is never
> going to work reliably.

We have no chance to plug all hole reliably anyway.  The closest to
"handle it everywhere" already exists, it's called cygwin-mount.el.
There's no point re-inventing it.  Instead we want something that's less
intrusive, even though it will miss a few more cases (but by being less
intrusive it can work better in the cases where it does work).


        Stefan

Re: A few Windows build fixes

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: andrewjmoreton@gmail.com,  emacs-devel@gnu.org
> Date: Mon, 05 Sep 2011 22:49:52 -0400
> 
> >> > It doesn't matter who and how runs "mount -m".  The results of that
> >> > should be used on the C level.  Otherwise, the result will be
> >> I don't think so: we only want to convert cygwin file names when they
> >> "enter" Emacs and everything else (e.g. all primitives that access
> >> files) should not know about them.
> > You cannot possibly hope to plug all the holes this way.  A file name
> > can "enter" Emacs in any number of ways, including as a substring of
> > some string or buffer.  Trying to catch all those loopholes is never
> > going to work reliably.
> 
> We have no chance to plug all hole reliably anyway.

Yes, we do: on the lowest possible level that Emacs handles file names
before it passes them to system APIs.  I pointed out the relevant
function in w32.c where that happens.  If you transform all file names
there, every single feature of Emacs will work as expected by users.

> The closest to
> "handle it everywhere" already exists, it's called cygwin-mount.el.

cygwin-mount is part of the solution, but it isn't all of it.  If we
want a reliable solution, that is (which IMO is what users expect).

> Instead we want something that's less intrusive, even though it will
> miss a few more cases (but by being less intrusive it can work
> better in the cases where it does work).

Something that happens in one or 2 functions cannot be intrusive.

Re: A few Windows build fixes

[Stefan Monnier]

> Yes, we do: on the lowest possible level that Emacs handles file names
> before it passes them to system APIs.  I pointed out the relevant
> function in w32.c where that happens.  If you transform all file names
> there, every single feature of Emacs will work as expected by users.

You're talking about adding support for cygwin file names at the very
lowest level?  Well, yes, that'd probably be just as reliable as
within cygwin.
We'd want it to have zero impact to the users who don't use cygwin
(and may not even have it installed), of course.

Also, once cygwin file names are supported, I think people will expect
more integration of (native) Emacs and cygwin, e.g. in subprocesses.


        Stefan

Re: A few Windows build fixes

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: andrewjmoreton@gmail.com, emacs-devel@gnu.org
> Date: Tue, 06 Sep 2011 14:04:01 -0400
> 
> > Yes, we do: on the lowest possible level that Emacs handles file names
> > before it passes them to system APIs.  I pointed out the relevant
> > function in w32.c where that happens.  If you transform all file names
> > there, every single feature of Emacs will work as expected by users.
> 
> You're talking about adding support for cygwin file names at the very
> lowest level?

I'm saying that this is the only way to have reliable support for
Cygwin file names (as opposed to something that only "mostly" works).

> We'd want it to have zero impact to the users who don't use cygwin
> (and may not even have it installed), of course.

They will never see such file names.

> Also, once cygwin file names are supported, I think people will expect
> more integration of (native) Emacs and cygwin, e.g. in subprocesses.

What problems are there with Cygwin subprocesses?  Emacs already
recognizes Cygwin executables and adapts itself, at least to some
extent (quoting of command-line arguments).

Re: A few Windows build fixes

[Stefan Monnier]

>> > Yes, we do: on the lowest possible level that Emacs handles file names
>> > before it passes them to system APIs.  I pointed out the relevant
>> > function in w32.c where that happens.  If you transform all file names
>> > there, every single feature of Emacs will work as expected by users.
>> You're talking about adding support for cygwin file names at the very
>> lowest level?
> I'm saying that this is the only way to have reliable support for
> Cygwin file names (as opposed to something that only "mostly" works).
>> We'd want it to have zero impact to the users who don't use cygwin
>> (and may not even have it installed), of course.
> They will never see such file names.

That can be argued (all file names starting with "/" are potential
Cygwin names).  But the issue I was referring to is that we want the
Emacs executable to work even if Cygwin is not available, so either we
have to re-implement the Cygwin file-name translation (as is partly done
in cygwin-mount) or we have to dyn-load the Cygwin run-time
when available.

>> Also, once cygwin file names are supported, I think people will expect
>> more integration of (native) Emacs and cygwin, e.g. in subprocesses.
> What problems are there with Cygwin subprocesses?  Emacs already
> recognizes Cygwin executables and adapts itself, at least to some
> extent (quoting of command-line arguments).

I thought we still had problems delivering signals to them.
If not, great.


        Stefan

Re: A few Windows build fixes

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: andrewjmoreton@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 06 Sep 2011 23:29:01 -0400
> 
> >> We'd want it to have zero impact to the users who don't use cygwin
> >> (and may not even have it installed), of course.
> > They will never see such file names.
> 
> That can be argued (all file names starting with "/" are potential
> Cygwin names).

I was talking about /cygdrive/x/ file names that should be translated
to x:/ and vice versa.  This must be on the C level, AFAIU.

The "mounted" file names, if we want or need to support them, will
have to be looked up in the mount list taken from "mount -m".  But I'm
not sure we need this, as /cygdrive/x/ should be sufficient.  However,
I don't use Cygwin, so maybe I'm missing some important use cases that
do need this.

> But the issue I was referring to is that we want the
> Emacs executable to work even if Cygwin is not available, so either we
> have to re-implement the Cygwin file-name translation (as is partly done
> in cygwin-mount) or we have to dyn-load the Cygwin run-time
> when available.

I don't see how the fact that Cygwin is or isn't installed is related
to implementing the translation, except that "mount -m" will fail if
Cygwin is not installed.  We can use this failure to disable
translation, or we can translate /cygdrive/x/ anyway, because it is
unlikely that a random w32 user will have a real /cygdrive/x/
directory on her disk.

Loading the Cygwin DLL into a native w32 process is impossible, so
that's not an option.

> I thought we still had problems delivering signals to them.

You are right, we don't support sending Posix signals to Cygwin
programs.  But where is that a real problem?  Emacs does know how to
interrupt a subprocess, and the way it does that should work with
Cygwin programs as well, albeit with less flexibility.  After all,
Cygwin programs are just specialized Windows applications.

Re: A few Windows build fixes

[Stefan Monnier]

>> >> We'd want it to have zero impact to the users who don't use cygwin
>> >> (and may not even have it installed), of course.
>> > They will never see such file names.
>> That can be argued (all file names starting with "/" are potential
>> Cygwin names).
> I was talking about /cygdrive/x/ file names that should be translated
> to x:/ and vice versa.  This must be on the C level, AFAIU.

For me, the convincing argument to add a "convert-external-file-name"
function to use on command-line args and such was specifically to be
able to handle *all* forms of Cygwin file names, including the ones that
are ambiguous (/home/foo was one motivating example, if I remember).
This was brought up in a feature-request for emacsclient arguments.

> The "mounted" file names, if we want or need to support them, will
> have to be looked up in the mount list taken from "mount -m".

FWIW, in that example, the mount point was "/some/where is mounted on /"
(and as it turns out the "mounted on /" is a case not handled by
cygwin-mount.el).  So /home/foo really meant /some/where/home/foo, but
to figure that out, we'd first have to decide whether to interpret
/home/foo as a Cygwin name or as a native name.

> I don't see how the fact that Cygwin is or isn't installed is related
> to implementing the translation, except that "mount -m" will fail if
[...]
> Loading the Cygwin DLL into a native w32 process is impossible, so
> that's not an option.

I see, so indeed, Cygwin's availability is irrelevant since we won't use
the Cygwin DLL anyway.

>> I thought we still had problems delivering signals to them.
> You are right, we don't support sending Posix signals to Cygwin
> programs.  But where is that a real problem?  Emacs does know how to
> interrupt a subprocess, and the way it does that should work with
> Cygwin programs as well, albeit with less flexibility.  After all,
> Cygwin programs are just specialized Windows applications.

It is a cause of problems for the SSL/TLS support (when we use
gnutls-cli rather than the gnutls DLL), for example.


        Stefan

Re: A few Windows build fixes

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: andrewjmoreton@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 07 Sep 2011 08:50:37 -0400
> 
> > The "mounted" file names, if we want or need to support them, will
> > have to be looked up in the mount list taken from "mount -m".
> 
> FWIW, in that example, the mount point was "/some/where is mounted on /"
> (and as it turns out the "mounted on /" is a case not handled by
> cygwin-mount.el).  So /home/foo really meant /some/where/home/foo, but
> to figure that out, we'd first have to decide whether to interpret
> /home/foo as a Cygwin name or as a native name.

File names on Emacs seldom come as "/foo/bar" without a drive letter.
So we can guess these names are Cygwin names.  But even if we don't
want to guess, checking for existent of a directory that is directly
under / is very fast, even on Windows.  So we could check that always,
and probably need a user variable to turn that off (for users who,
like me, will never install Cygwin).

> >> I thought we still had problems delivering signals to them.
> > You are right, we don't support sending Posix signals to Cygwin
> > programs.  But where is that a real problem?  Emacs does know how to
> > interrupt a subprocess, and the way it does that should work with
> > Cygwin programs as well, albeit with less flexibility.  After all,
> > Cygwin programs are just specialized Windows applications.
> 
> It is a cause of problems for the SSL/TLS support (when we use
> gnutls-cli rather than the gnutls DLL), for example.

If someone writes code to deliver signals to Cygwin processes, I'm
sure we will accept the patches.  I know nothing about that except
that it uses some Cygwin-specific magic.

Re: A few Windows build fixes

[Hannu Koivisto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
>> Also, once cygwin file names are supported, I think people will expect
>> more integration of (native) Emacs and cygwin, e.g. in subprocesses.
>
> What problems are there with Cygwin subprocesses?  Emacs already
> recognizes Cygwin executables and adapts itself, at least to some
> extent (quoting of command-line arguments).

One problem is Cygwin dll's automatic globbing of command line
arguments (which is done when a non-Cygwin application runs a
Cygwin application) and that might be one thing that could be
handled if better integration is wanted.  I faced this problem with
an Emacs git interface package that in my system would run Cygwin
git directly (not via shell) with a parameter like "foo^{commit}"
and due to the automatic globbing git actually saw "foo^commit" and
there was an error.  It took some head scratching to figure out
what was going on :)  Fortunately that (mis)feature can be forced
off using the CYGWIN environment variable (see
http://www.cygwin.com/cygwin-ug-net/using-cygwinenv.html,
(no)glob), so I was able to add a workaround to this package.

-- 
Hannu

Re: A few Windows build fixes

[Eli Zaretskii]

> From: Hannu Koivisto <azure@iki.fi>
> Date: Thu, 08 Sep 2011 11:33:04 +0300
> 
> One problem is Cygwin dll's automatic globbing of command line
> arguments (which is done when a non-Cygwin application runs a
> Cygwin application) and that might be one thing that could be
> handled if better integration is wanted.

Sorry, I don't understand.  On Posix platforms, globbing is something
done by the shell, not by the application.  Since Cygwin emulates
Posix, I would expect its applications not to glob on their own.  Are
you saying that sometimes Cygwin applications do glob in their startup
code, like native Windows apps?  (That's what I understand from the
URL you mentioned.)

Anyway, there's code in Emacs and cmdproxy to treat Cygwin
applications specially.  Perhaps that code needs to be updated for the
current behavior of Cygwin programs.  If so, I would welcome Cygwin
users to provide patches to that effect.  Only those users have both
the motivation to fix Emacs in this area and the means to test these
patches.

TIA

Re: A few Windows build fixes

[Hannu Koivisto]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Hannu Koivisto <azure@iki.fi>
>> Date: Thu, 08 Sep 2011 11:33:04 +0300
>> 
>> One problem is Cygwin dll's automatic globbing of command line
>> arguments (which is done when a non-Cygwin application runs a
>> Cygwin application) and that might be one thing that could be
>> handled if better integration is wanted.
>
> Sorry, I don't understand.  On Posix platforms, globbing is something
> done by the shell, not by the application.

Right.  And this is something some Emacs packages (such as the git
interface I was talking about) rely on.

> Since Cygwin emulates Posix, I would expect its applications not
> to glob on their own.

They don't when you run them from a Cygwin shell or any other
Cygwin application.  They (well, not the applications as such but
the cygwin dll linked to them) do when you run them from a native
Windows application.

Apparently the idea is that a person using cmd.exe, for example,
can say "ls foo*" and have it work in an "expected" way.
Unfortunately this feature is not limited to cmd.exe (even though
some documentation suggests so).

> Are you saying that sometimes Cygwin applications do glob in
> their startup code, like native Windows apps?  (That's what I
> understand from the URL you mentioned.)

Yes.

-- 
Hannu

Re: A few Windows build fixes

[Vijay Lakshminarayanan]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Thu 01 Sep 2011, Vijay Lakshminarayanan wrote:
>
>>
>>
>> Going through w32-fns.el, I see there's `w32-convert-standard-filename'
>> which actually replaces /cygdrive/ paths correctly.  Indeed, 
>>
>> (convert-standard-filename
>>  "/cygdrive/c/programs/emacs-24.0.50/lisp/w32-fns.el")
>>
>> ; => "c:\\programs\\emacs-24.0.50\\lisp\\w32-fns.el"
>>
>> does the right thing.
>
> This is buggy. The '/cygdrive' prefix can be replaced per-user or system
> wide - see the cygwin mount(1) manpage for details.

You're absolutely right.  This means that w32-convert-standard-filename
is broken.  Should I (or someone else) raise a bug?

>     AndyM

-- 
Cheers
~vijay

Gnus should be more complicated.

Re: A few Windows build fixes

[Stefan Monnier]

> Going through w32-fns.el, I see there's `w32-convert-standard-filename'
> which actually replaces /cygdrive/ paths correctly.  Indeed, 

Well, that's a bug: convert-standard-filename was meant for something
completely different and has degenerated into an ugly beast whose
behavior is a big mess, so we need a new function instead which is
clearly documented as translating a file-name "valid in the system,
outside of Emacs" into a filename "valid within Emacs".  And it needs to
be hookable so that users can add things like "proper/careful handling
of cygwin file names", as opposed to merely handling "/cygdrive/...".


        Stefan