[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: make 3.81 MinGW port and testsuite working with MSYS
From: |
Eli Zaretskii |
Subject: |
Re: make 3.81 MinGW port and testsuite working with MSYS |
Date: |
Wed, 02 Mar 2005 06:58:06 +0200 |
> 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.