Re: A few Windows build fixes

[Eli Zaretskii]

> From: Hannu Koivisto <address@hidden>
> 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.