[CMake] to_cmake_path/to_native_path oddities

Bill Hoffman bill.hoffman at kitware.com
Wed May 28 13:14:48 EDT 2008


Axel Roebel wrote:

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

set environment variables CC,CXX, and FC to the compilers you want cmake 
to use before you run cmake, and it should work.

> 
> 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.
> 
What error do you get?
> 
...
>>> 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.

It is not meant to be used in the cygwin environment.  That should be a 
complete unix path environment.
> 
> 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?
Again, this is a Windows env being used from cygwin.
> 
> It seems to me that a TO_CMAKE_PATH that transforms to unix should assume that 
> the input path is in windows form (; separators).
But it would break when you passed it a cygwin path.   You can always 
make your own macro in cmake to do this for you with string replace or 
regex.

> 
>> 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. 
> 
That is really not something we support.   I would recommend just 
setting the INCLUDE path to be different for cygwin.  Or, since you are 
using your own redirection shell script, the script could automatically 
add the -I path for you.

> I agree this enviroment is  not common. I still believe though that the 
> TO_CMAKE_PATH is 
> 
The intention for TO_CMAKE_PATH, was when you were running on a native 
windows build and needed to convert from the windows paths into cmakes 
native POSIXs style paths.  It was not meant to transcribe from native 
windows to cygwin.

-Bill


More information about the CMake mailing list