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

[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?

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.

  >> 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? :-).

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.

  >> 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.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist