Re: Savannah W32 patches... are any OK?

[Eli Zaretskii]

> Date: Sun, 27 Feb 2005 16:41:22 -0500
> From: "Paul D. Smith" <address@hidden>
> 
> There are a number of W32 patches posted on Savannah, that I don't know
> whether they should be applied or not.  I need someone from the W32 team
> to take a look and see if they make sense.

How much time do we have to review and discuss these?

>   https://savannah.gnu.org/patch/index.php?func=detailitem&item_id=3679
> 
>     > CTRL-C on Windows causes make to crash. This was because of the
>     > wrong implementation of w32_kill, dereferencing a pid as a
>     > pointer. The attached patch (targetting mingw32-make-3.80.0-3)
>     > fixes it.
> 
>     This seems straightforward enough but Alessandro posted a followup
>     that said the change given was not correct and a different solution
>     was needed... any thoughts on this?

I tend to agree with Alessandro, but a specific patch he suggests
would be nice: it's hard to think about this on purely theoretical
grounds.

>     There was a bunch of discussion about this one by Eli etc. pointing
>     out the enhanced command.com is only available on newer versions of
>     Windows.  I was hoping someone would provide a way to determine at
>     runtime whether the more capable command.com was available.

One could do that by looking at the Windows version.  If we are on
Windows 2000 or XP (or later versions), then CMD.EXE (not command.com,
which is for DOS and Windows 9X) is clever enough.

>   https://savannah.gnu.org/patch/index.php?func=detailitem&item_id=2608
> 
>     > One challenging aspect of a port of GNU make to Win32 has been
>     > what to do with Win32's case-retentive (but not case-sensitive)
>     > environment. I suggest that one good way of handling this problem
>     > is to simply uppercase all environment variable names when they
>     > are merged into the make database. That way, makefile writers on
>     > Win32 can just assume that all environment variable names are
>     > uppercase. While this may seem nasty at first, we must consider
>     > the fact that one cannot enter VarName, varname, and VARNAME at
>     > the same time. Furthermore, if you set a variable called
>     > VarName=Something, then later, in the same environment, set
>     > VARNAME=Something (or SomethingElse), the variable name case is
>     > retained from the first entry! This being the case, it's far
>     > better just to uppercase them all on input. The other option would
>     > be to perform case-insensitive string comparisons on variable
>     > names, but the make variable name comparison code doesn't
>     > differentiate between variables that came from the environment and
>     > those defined internally, so this becomes problematic. A better
>     > approach is to simply normalize environment variable names and
>     > document this fact to Win32 GNU make users.
> 
>     This seems crazy to me, coming from my cushy UNIX-centric world :-),
>     but there are some good arguments here and so if the W32 team thinks
>     it's a good idea, it's fine with me.

It seems crazy to me as well, especially since I don't understand what
was the original problem that such case-insensitive treatment of
environment vars is supposed to solve.  Can someone enlighten me about
the opriginal problem?

>     If we do this does it make
>     sense to do it with the DOS port as well?

The DOS port makes a point of being case-sensitive as far as the
environment variables go.  It never caused any problems, so I'm
curious why the Windows port cannot do the same.

>   https://savannah.gnu.org/patch/?func=detailitem&item_id=1140
> 
>     > Additional builtin rules for NT
> 
>     This adds builtin rules for .obj suffixes, anywhere a .o suffix
>     appears in the standard builtin rules.  I don't know that this is a
>     good idea on non-Windows systems, but I'd be willing to put it into
>     an #ifdef for DOS/Windows systems if you think it's useful.

Not on DOS, please.  The DJGPP development environment uses GCC as its
compiler, and object files are called *.o, not *.obj.  If Windows
users need that for the sake of Microsoft's compiler, I don't mind
(but then it should probably be mentioned in some footnote in the
manual).