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

[Cesar Rabak]

Since the cmake is ported to the Windows platform/environment, I think it is reasonable expectation of the user to have the env vars written in the native (Windows) style.

As such, cmake must be able to parse and process vars with spaces and correctly interpreting the backslashes.

As matter of fact, this should be transparent for cmake, after of all the programs that make use of the information stored in these variables that have to take care of the semantics of the slashes.

my .01999...


"William A. Hoffman" <billlist at nycap.rr.com> escreveu: 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



-- 
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
		
---------------------------------
 Yahoo! doce lar. Faça do Yahoo! sua homepage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/cmake/attachments/20060212/6306e57c/attachment.htm