[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Savannah W32 patches... are any OK?
From: |
Alessandro Vesely |
Subject: |
Re: Savannah W32 patches... are any OK? |
Date: |
Mon, 28 Feb 2005 12:43:21 +0100 |
"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
Re: Savannah W32 patches... are any OK?, Alessandro Vesely, 2005/02/28