Re: A few Windows build fixes

[Hannu Koivisto]

Eli Zaretskii <address@hidden> writes:

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