Savannah W32 patches... are any OK?

[Paul D. Smith]

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.  Most, if not all, have been
mentioned on the make-w32 list before but I don't recall any
discussion/decision on them.

FYI:

  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?


  https://savannah.gnu.org/patch/index.php?func=detailitem&item_id=3678

    > make -j currently requires a Bourne shell on Windows. This isn't
    > actually necessary, and it appears to be caused by ignorance of
    > the enhancemente of the Windows command prompt on its ancestor,
    > the DOS prompt. The attached patch (targetting
    > mingw32-make-3.80.0-3) fixes this

    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.  Failing
    that we'll either have to keep things as they are, or possibly
    provide a configuration option to enable support for the newer
    command.com (this would be concerning since it means a make built
    like that wouldn't be usable on older versions of Windows, but...)


  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.  If we do this does it make
    sense to do it with the DOS port as well?


  https://savannah.gnu.org/patch/index.php?func=detailitem&item_id=3747

    > I didn't test this patch deeply. Apparently, gmake becomes neither
    > worst nor better with it. However, this patch may be useful for
    > experimenting with CreateProcess, or avoiding the inheritance
    > problem in CreatePipe. So, here is it.

    Not sure whether this should be applied, or not.  It has a few other
    items in it besides the CreateProcess() change.


  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.

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