[CMake] to_cmake_path/to_native_path oddities

[Axel Roebel]

On Wednesday 28 May 2008, Bill Hoffman wrote:
> 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

Thanks Bill,

> So, we added more places to look for things (INCLUDE). 

I see, that explains at least why it does not work anymore.

> 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.

Unix makefile generator with windows binary was our first trial. How can I set 
the compiler to use ? icl is not the standard compiler for unix makefiles?
Anyway, I doubt that windows cmake will convert pathes to unix style before
writing it into the unix makefile. As far as I saw it didn't. 

Yes  NO_DEFAULT_PATH is probably the best fix to this problem. I tried that 
already.

> > 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.

I would like to, but I actually can't in cmake. I think this is a problem
of cmake.


> > 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

Could you explain to me what conversion TO_CMAKE_PATH is actually doing if you 
supply it $ENV{PATH} in a cygwin environment. It seems to me that it wouild 
not do anything because the result is already in unix format.

If however I used $ENV{INCLUDE} it would not work. So from the two possible 
situations this command seems to work only for the one that is useless
unix -> unix. may be I am missing something here?

It seems to me that a TO_CMAKE_PATH that transforms to unix should assume that 
the input path is in windows form (; separators).

> 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?

My main platforms are Linux and MacOSX, but I have to support Windows MSVC, 
gcc and icl. All my test scripts are unix shell scripts that will be run as 
makefile targets (using cygpath to adapt pathes). 
So I prefer my environment as unix like as possible. 
Accordingly, I wrote an icl redirection shell script replacing all unix paths 
by equivalent windows paths. 
So -I/cygdrive/c/ProgramFiles/Intel/MKL/10.0.1.014/include
is perfect for me. 

I agree this enviroment is  not common. I still believe though that the 
TO_CMAKE_PATH is 


> -Bill



-- 
Axel Roebel    
IRCAM Analysis/Synthesis Team
Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540