[vtk-developers] [bug] wrong CMAKE_COMMAND (win32)

John Biddiscombe jbiddiscombe at skippingmouse.co.uk
Fri Aug 31 12:26:33 EDT 2001


I've had many problems with slashes forward and back during my 
implementation of a Borland compatible module for cmake. My solution up 
till now has been to convert to unix slashes by default, but when I get 
errors I replace forward slashes with '¬' and have a small convert ¬ to \ 
at the end of everything. I did add a CleanUpWindowsPaths command to 
SystemTools and it is very useful for small pieces of code that need it. I 
found that the Borland compiler works fine with forward slashes, but TLIB 
doesn't like them as it uses '/' as options on the command line whereas the 
compiler uses -option syntax and couldn't care about the slashes.

This particular problem appears to be typical of CMake. It is supposed to 
be Cross-platform, but hard codes an platform specific details in it. 
(Remove the "C" perhaps!)

JB


At 16:47 31/08/2001, Sebastien BARRE wrote:
>Hi
>
>First of all, I do apologize, I'm using Windows 98. I have to. I'm stuck 
>with it until I get a new computer at my new job :)
>
>Anyway, I still have some work and while trying to reinstall all my 
>framework within Win98, I found the following problem, preventing me from 
>compiling VTK :
>
>In cmake.cxx :
>
>// at the end of this CMAKE_ROOT and CMAKE_COMMAND should be added to the 
>cache
>void cmake::AddCMakePaths(const std::vector<std::string>& args)
>{
>   // Find our own executable.
>   std::string cMakeSelf = args[0];
>   cmSystemTools::ConvertToUnixSlashes(cMakeSelf);
>[...]
>   cmCacheManager::GetInstance()->AddCacheEntry
>     ("CMAKE_COMMAND",
>      cmSystemTools::EscapeSpaces(cMakeSelf.c_str()).c_str(),
>[...]
>
>The CMAKE_COMMAND holds the path to cmake.exe. Could you please remember 
>me why we need to convert to Unix Slashes ?
>
>The problem is the following :
>
>Once the above code has been run, here is my CMAKE_COMMAND (from the cache) :
>
>//Path to CMake executable.
>CMAKE_COMMAND:INTERNAL="E:/SRC/KITWARE/CMAKE/SOURCE/cmake.exe"
>
>(indeed, among all other .exe found in my cache (TCL_TCLSH, TK_WISH, 
>VTK_WRAP_TCL_EXE), CMAKE_COMMAND is the only one that was space-escaped).
>
>Now it makes its way to the DSP files, for example :
>
>"vtksbIOTCL.dsp" :  "$(SOURCE)" "$(INTDIR)" "$(OUTDIR)"
>         "E:/SRC/KITWARE/CMAKE/SOURCE/cmake.exe" 
> D:/users/barre/devel/these/c++/vtknew/IO/CMakeLists.txt -DSP 
> -H"D:/users/barre/devel/these/c++/vtknew" 
> -S"D:/users/barre/devel/these/c++/vtknew/IO" 
> -O"E:/src/kitware/SB/build/IO" -B"E:/src/kitware/SB/build"
>
>and msdev put that "custom build" step in a .bat file, which is run. But 
>it fails, because cmake.exe can not be called like that.
>
>In Windows 98, you can do that :
>         E:\SRC\KITWARE\CMAKE\SOURCE\cmake.exe
>         "E:\SRC\KITWARE\CMAKE\SOURCE\cmake.exe"
>
>but you can't do that, it fails (at least at home) :
>         "E:/SRC/KITWARE/CMAKE/SOURCE/cmake.exe"
>         E:/SRC/KITWARE/CMAKE/SOURCE/cmake.exe
>
>I guess we need to escapes spaces, but disabling the conversion to Unix 
>slashes for this specific var would actually solve the problem. But I 
>guess this has been done for good reason ?
>Another problem is that this conversion to Unix slashes is done twice : 
>the call to FindProgram use CollapseFullPath which itself use 
>ConvertToUnixSlashes (why ?). Hence, we are in trouble.
>
>For this specific case, what can we do ? Add a ConvertToWindowsSlashes and 
>surround it with a #ifdef _WIN32 to convert the path back to Windows syntax ?
>
>What do you think ?
>
>_______________________________________________
>vtk-developers mailing list
>vtk-developers at public.kitware.com
>http://public.kitware.com/mailman/listinfo/vtk-developers





More information about the vtk-developers mailing list