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

[Earnie Boyd]

<quote who="Paul D. Smith">
> %% "Eli Zaretskii" <address@hidden> writes:
>
>   >> 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.
>
>   ez> How much time do we have to review and discuss these?
>

Nor for I.

> Heh.  Well, my goal was to get a new release out this week (Tuesday is 1
> Mar).  If there is a serious desire and effort to get these worked out I
> can hold it for a few days.
>

Thank you.

>   >> 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?
>
>   ez> I tend to agree with Alessandro, but a specific patch he suggests
>   ez> would be nice: it's hard to think about this on purely theoretical
>   ez> grounds.
>
> I agree; so we're waiting for someone to provide an updated patch here.
>
>   >> 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.
>
>   ez> One could do that by looking at the Windows version.  If we are on
>   ez> Windows 2000 or XP (or later versions), then CMD.EXE (not
> command.com,
>   ez> which is for DOS and Windows 9X) is clever enough.
>
> Well, yes, but how does one look at the Windows version? :-).
>

The basename value of the COMSPEC variable should be enough; if == cmd.exe
then NT else DOS.  You might wish a command line switch for those who've
replaced their windows shell with something else and have changed the
COMSPEC value; E.G. -O [DOS|NT].

> Again, we're waiting for a patch from someone that you all can agree on
> and I can actually apply.
>
>   >> 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.
>
>   ez> It seems crazy to me as well, especially since I don't understand
>   ez> what was the original problem that such case-insensitive treatment
>   ez> of environment vars is supposed to solve.  Can someone enlighten
>   ez> me about the opriginal problem?
>
>>From the description above it seems like if the makefile expects a
> variable from the environment called SOMEVARIABLE, but you set
> SomeVariable in your environment, make won't treat them as the same even
> though Windows (and DOS?) apparently DOES consider them the same.
>
> Also, if you set SomeVariable, then later set SOMEVARIABLE, apparently
> the OS retains the first spelling (SomeVariable) so again this won't
> work with your makefile expecting SOMEVARIABLE.  I suppose you'd have to
> unset SomeVariable completely, then set SOMEVARIABLE.
>
> I can see where this is confusing, somewhat.  I don't know that it's
> confusing enough to warrant a force-uppercase for the entire
> environment.
>

I don't understand the problem with this either.  The getenv function is
case insensitive according to MSDN.  Why then would it matter how the
environment variable is stored?

>   >> 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.
>
>   ez> Not on DOS, please.  The DJGPP development environment uses GCC as
> its
>   ez> compiler, and object files are called *.o, not *.obj.  If Windows
>   ez> users need that for the sake of Microsoft's compiler, I don't mind
>   ez> (but then it should probably be mentioned in some footnote in the
>   ez> manual).
>
> OK, I'll wait for the Windows folks to give an opinion here.
>

Adding a .obj builtin rule would be good even for DOS.  Removing the .o
rule would be bad even for windows.  It wouldn't even hurt to have the
.obj builtin on non Windows systems; IIRC VAX defaults to .obj and I know
of several still in use.  The .obj should just be a synonym for .o.

I can see for future releases builtin rules for .dll and .exe as well.


Earnie

--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438