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

[Alessandro Vesely]

"Paul D. Smith" wrote:
> 
> %% "Eli Zaretskii" <address@hidden> 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