Re: Windows patches for the next release

[Eli Zaretskii]

> From: Paul Smith <address@hidden>
> Cc: Denis Excoffier <address@hidden>,
>  address@hidden,  address@hidden, address@hidden
> Date: Sat, 05 Oct 2013 20:05:03 -0400
> 
> > > However, output-sync, recursion, MAKE remain.  Included work.tar.xz
> > 
> > All of those failures are because of the exact form of $(MAKE).  What
> > Cygwin produces is functionally equivalent to what the test suite
> > expects, so I think we can consider these failures redundant, if not
> > bogus.  (If Paul accepts your patch to the suite, they will be gone
> > altogether.)
> 
> Personally I think this is a real bug.  Make should try to use the
> fully-qualified pathname when it sets the MAKE variable, which is why
> the test suite prefixes the filename with the current working directory
> if the path is determined to be relative.
> 
> If MAKE is set to a relative pathname, then it will fail in recursion
> when the directory is changed, since $(MAKE) will no longer be a valid
> path.
> 
> Won't it?

Once again, I think this is the issue with "." being on PATH, which is
always the case on Windows.  If you add "." to PATH, Posix Make fails
as well.

We need a general solution here.

OTOH, since I cannot build and debug the Cygwin port, perhaps I'm
missing something here.  It would be nice if someone who actually uses
Cygwin could run Make under a debugger in these cases, and see why you
get "../make" instead of an absolute file name.