"Paul D. Smith" wrote: > > %% "Eli Zaretskii" <[EMAIL PROTECTED]> writes: > > [...] > > >> 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.
The analisys above is not fully correct: NT distinguishes two kinds of environment, system variables and user variables. Thus, setting a variable with different case in the other environment still creates two variables with the same uppercase name. Typically, that occurs when PATH has been set as a system variable and Path has been added by GNU make as a user variable. > >> > >> 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. Add to this that Win32 utilities are often inconsistent about the spelling of a variable: Since the OS retrieves variables case-insensitivitely, they feel free to amend the spelling across versions to increase readability. > 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 Agree. Furthermore, the patch doesn't change the case of variables set by GNU make (i.e. set PATH rather than Path.) IMHO, a more interesting solution to this problem is to have a getenv function. It may be useful in Unix too, as it would allow to retrieve a variable from the environment even after its value has been overridden. Note that Guile already has two such functions, getenv and scm_getenv: http://www.gnu.org/software/guile/docs/guile-ref/Runtime-Environment.html _______________________________________________ Make-w32 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/make-w32
