[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