[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Savannah W32 patches... are any OK?
Paul D. Smith
Savannah W32 patches... are any OK?
Sun, 27 Feb 2005 16:41:22 -0500
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.
> 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?
> 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...)
> 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?
> 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.
> 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:
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
Re: Savannah W32 patches... are any OK?, Alessandro Vesely, 2005/02/28