Re: Windows patches for the next release

[Paul Smith]

On Sun, 2013-10-06 at 05:52 +0300, Eli Zaretskii wrote:
> > 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.
> 
> 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.

I think this isn't the same problem.  That's a very special case, where
argv[0] has no directory separator at all.  In that case probably the
ultimately right thing to do is search PATH looking for the
fully-qualified pathname and, if THAT is relative, prepend the current
directory.  But that's not what we do and I don't have a problem with
our current behavior: if you're going to add "." to your PATH then
obviously when you change directories programs may not be found anymore.
Adding "." to your PATH is a very bad idea for all sorts of reasons.

In this case, argv[0] has a separator but is not absolute.  That's
handled differently in the code in main.c: in that case we prepend the
current working directory to the existing path.  So if you're
in /tmp/foo and you run "../make" then MAKE will be set to
"/tmp/foo/../make".  That way if you recurse into a different directory,
MAKE will still be the correct valid pathname.