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
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
