[CMake] to_cmake_path/to_native_path oddities

[Bill Hoffman]

Axel Roebel wrote:
> Hi,
> 
> I just switched from 2.4.8 to 2.6 and found a very strange behavior in one of my existing cmake 
> projects. I am trying to find the include files (and libraries) of Intels  mkl libraries with the following
> cmake code
> 
> FIND_PATH(MKL_INCLUDE_PATH_TMP mkl_dfti.h PATHS /usr/include  /usr/local/include  /u/formes/share/include  /cygdrive/c/Program 
> Files/Intel/MKL/10.0.1.014/include)
> 
> Now in cmake 2.4.8 this returned 
> 
> /cygdrive/c/Program Files/Intel/MKL/10.0.1.014/include
> 
> while in cmake 2.6.0 it creates
> 
> c:\Program Files\Intel\MKL\10.0.1.014\include
> 
> a path that it found in the environment variable INCLUDE
> 

So, we added more places to look for things (INCLUDE).  You may want to 
try the Unix Makefile generator and the windows binary of cmake.  The 
cygwin cmake really does not work very will with native windows 
programs.  It really is meant to work in the cygwin environment with the 
cygwin tool chain.  You could add NO_DEFAULT_PATH to your FIND_PATH call 
and it would stop cmake from looking in INCLUDE.

> This seems already somewhat buggy tpo me because I would have expected that in a unix makefile generator the variable should be automatically
> converted to unix path style.
> 
The path should be converted before it is actually used if you pass it 
to say include_directories.

> Then I thought to use the to_cmake_path/to_native_path facilities to convert the path
> to unix flavor. (BTW I am not quite sure what native means in cygwin compiled cmake on windows).
> Neither of these two did anything useful though. Both ended up with something like
> 
> "c"  "/Program Files/Intel/MKL/10.0.1.014/include"
> 
> which after looking in the source code is obviously due to the fact that 
> the fist thing both TO_*_PATH commands do is
> 
>  #if defined(_WIN32) && !defined(__CYGWIN__)
>   char pathSep = ';';
> #else
>   char pathSep = ':';
> #endif
>   std::vector<cmsys::String> path = cmSystemTools::SplitString(i->c_str(),    pathSep);
> 
> this means for CYGWIN it will always use ":" as path separator splitting the c from the 
> rest and then converting to unix style path. So in short the path conversion for cygwin
> is working only in one (completely useless) case: 
> 
> unix style path -> unix style path 
> 
> While I submitted this as a bug report I wonder if there are any workarounds that
> I might use to get the unix style path with the current cmake 2.6.0
> 

We would have to create a new command to do that.   If you check the 
docs for TO_CMAKE_PATH, it says you can pass in things like:
$ENV{PATH}, so it allows for and was intended to work with paths 
separated by the native path separator.    Again, cygwin does not play 
nice with windows tools.   I mean if you passed -I/cygdrive/c/Program 
Files/Intel/MKL/10.0.1.014/include  to the intel compiler, it would not 
be able to use it would it?

-Bill