[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Savannah W32 patches... are any OK?
From: |
Earnie Boyd |
Subject: |
Re: Savannah W32 patches... are any OK? |
Date: |
Tue, 1 Mar 2005 06:32:41 -0500 (EST) |
User-agent: |
SquirrelMail/1.4.3a |
<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