[CMake] problem on windows with $ENV{something}

[David Cole]

I'd have to vote for this as a "feature" actually. I think 
"$ENV{something}" should evaluate to exactly the value of the 
environment variable and nothing more. Any transformations have to be up 
to the user because we can't know what the environment variable 
represents...

Having said that... perhaps there should be an easier way to say "take 
this value that I got from the environment and transform it into a CMake 
friendly path"...

The "string(regex replace ...)" technique works, but has to be 
conditonalized on ... what? WIN32 and NOT UNIX...? Finding a "\\" in the 
result of $ENV{something}"? What's the ultimate cross-platform 
recommendation?


Fuel for the fire,
David


William A. Hoffman wrote:

>At 09:21 AM 2/12/2006, Alexander Neundorf wrote:
>  
>
>>Hi, 
>>
>>it seems there's an issue with using $ENV{something} under windows, as 
>>can be read here and followups: 
>>http://mail.kde.org/pipermail/kde-buildsystem/2006-February/001083.html 
>>
>>The problems is that if the environment variable contains backslahes (and 
>>maybe spaces), it breaks the dependency scanning of cmake, i.e. 
>>dependencies are not scanned. This has been reported for nmake. 
>>
>>A workaround is to replace all backslahes to forward slashes using 
>>string(regex replace ...) 
>>
>>Is this a bug or a feature ? 
>>    
>>
>
>The problem is that CMake expects all paths to be unix style paths.
>ENV on Windows is likely to produce a windows path with \ and not /,
>that is likely to mess up the cmake parser.  So, should CMake ENV
>try to convert slashes?   The problem is, it may or may not be a PATH.
>We could check to see if it is a PATH?  Or we could create ENVPath{var}.
>Ideas, suggestions?
>
>Thanks.
>
>-Bill
>
>
>_______________________________________________
>CMake mailing list
>CMake at cmake.org
>http://www.cmake.org/mailman/listinfo/cmake
>
>  
>