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