[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