> 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. > > 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. _______________________________________________ Make-w32 mailing list Make-w32@gnu.org https://lists.gnu.org/mailman/listinfo/make-w32
