<quote who="Alessandro Vesely"> > "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. >
I thought I had remembered something like this, but couldn't remember the scenario that caused it. However, shouldn't the C runtime getenv return the variable from the USER space and not the SYSTEM space? >> >> >> >> 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. > I don't see why it matters! Can you give an example of where the case of the environment variable name matters w.r.t. Make? >> 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 > Why does Make need its own version of getenv? Why won't the provided getenv function from the C runtime work? Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 _______________________________________________ Make-w32 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/make-w32
