Re: make 3.81 MinGW port and testsuite working with MSYS

[Eli Zaretskii]

> Date: Wed, 02 Mar 2005 00:19:45 +0000
> From: "J. Grant" <address@hidden>
> CC: address@hidden,  address@hidden
> 
> 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.