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

[Earnie Boyd]

<quote who="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.
>

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