[CMake] to_cmake_path/to_native_path oddities
Axel Roebel
Axel.Roebel at ircam.fr
Wed May 28 10:40:11 EDT 2008
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
More information about the CMake
mailing list