> Date: Wed, 02 Mar 2005 00:19:45 +0000 > From: "J. Grant" <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED], [email protected] > > For instance, the output from the MSYS port of make: > > $ make -fmissing.mak > make: missing.mak: No such file or directory > make: *** No rule to make target `missing.mak'. Stop. > > In my view the MinGW port should also have the same output, without any > OS specific program executable file type suffix.
Why, because MSYS did that? I'd say, let's ask MSYS people to leave .exe as we do. > > As I already said, the DJGPP port was showing "make.exe" for years, > > and it was never a problem. I don't think we should change it now, as > > it could break something that relies on this, e.g. in sub-make's, or > > the value of the $MAKE variable. I say, let's leave the .exe alone. > > Removing the .exe extension did not cause any increase in test failures I wasn't talking about the test suite, I was talking about packages out there that are not part of Make. > (it actually caused 1 failure reduction). Which failure was that? It's probably some bug that needs exploring, since I see no .exe-related failures with the DJGPP port. > See sub_proc.c:318 find_file() to see the function which gets > "c:/path/to/make" and then tries in turn to get a valid handle on the > .exe, .cmd and .bat extensions of that program, as it does not find, it > finally tries without an extension which is the only case that succeedes > because "c:/path/to/make.exe.exe", "c:/path/to/make.exe.cmd", > "c:/path/to/make.exe.bat", do not find anything. Perhaps that function should be rewritten to see first if we already have make.exe, and only after that try adding extensions. > > Why did you need this snippet? The test for '/' or '\' was already > > done above, so what case does this handle? > > If the environment gave a partial invalid argv[0] containing: > > "p:" > > Then the additional unchecked ++program;, would mean that program was > potentially pointing to an area of memory after the '\0' of "p:". If that is the case, I don't mind to be a little more defensive. _______________________________________________ Make-w32 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/make-w32
