On Sun, 2013-10-06 at 05:52 +0300, Eli Zaretskii wrote: > > From: Paul Smith <psm...@gnu.org> > > Cc: Denis Excoffier <cyg...@denis-excoffier.org>, > > bug-...@denis-excoffier.org, pavel_fe...@mail.ru, make-w32@gnu.org > > 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. _______________________________________________ Make-w32 mailing list Make-w32@gnu.org https://lists.gnu.org/mailman/listinfo/make-w32