Mark Hindess wrote:
> I'll let Geir speak for himself, but I think he was alluding to the use
> of a user properties file:
>
> <property file="${user.home}/.harmony.properties" />
>
> that would *not* be checked in and would be read (if it existed or
> ignored otherwise).
>
> Which is exactly what you can achieve in a platform-independent way with
> a property file as described above.
This solution is okay with me.
>> And by the way, the solution to run 'HY_CFG=xyz ant' with
>> corresponding
>> <property environment="env"/>
>> <condition property='hy.cfg' value='${env.HY_CFG}'>
>> <isset property="env.HY_CFG"/>
>> </condition>
>> worked perfectly for the DRLVM builds on Windows. What's more,
>> it is *compatible* with 'ant -Dhy.cfg=...' syntax.
>>
>> I have not heard any specific concerns why this can't be used.
>
> Read the list archive. Environment variables are platform-specific and
> differ - if they exist - from platform to platform. Windows for example
> treats environment variable names as case-insensitive but when ant reads
> them from env.VaR you must get the case exactly right. Ant properties
> are platform-independent and so will work the same everywhere.
I have read the discussion, and still consider this as non-issue,
because anyone can be careful enough to define the name in correct case.
(So one must define the variable in proper case as HY_CFG even on Windows)
In my practice, environment variables worked fine on Windows.
And I have not heard a single report on how environment variables failed in
real life.
I have only seen discussion how this *may* fail if the user is not careful
enough
to do precisely what is written in instruction.
Still unconvinced why we can't allow careful users to use environment
variables for configuration.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
