[Cmake] Re: [vtk-developers] [bug] wrong CMAKE_COMMAND (win32)

[Sebastien BARRE]

At 31/08/01 17:26, John Biddiscombe wrote:
>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 missed that one.

OK, if I add in cmake.cxx :

#if defined(_WIN32)
   cmSystemTools::CleanUpWindowsSlashes(cMakeSelf);
#endif

right before

   cmCacheManager::GetInstance()->AddCacheEntry
     ("CMAKE_COMMAND",
      cmSystemTools::EscapeSpaces(cMakeSelf.c_str()).c_str(),
      "Path to CMake executable.",
      cmCacheManager::INTERNAL);

then it does the trick...

But it fails miserably later, and this looks once again a bit dirty :
msdev.exe crash because the Tcl wrapper also use '/' instead of '\' :

VTK_WRAP_TCL_EXE:FILEPATH=E:/src/kitware/VTK/new/build/bin/$(IntDir)/vtkWrapTcl.exe

So I had a look at cmUtilitySourceCommand::InitialPass() :

   // Enter the value into the cache.
   m_Makefile->AddCacheDefinition(cacheEntry.c_str(),
                                  utilityExecutable.c_str(),
                                  "Path to an internal program.",
                                  cmCacheManager::FILEPATH);

   // add a value into the cache that maps from the
   // full path to the name of the project
   cmSystemTools::ConvertToUnixSlashes(utilityExecutable);
   m_Makefile->AddCacheDefinition(utilityExecutable.c_str(),
                                  utilityName.c_str(),
                                  "Executable to project name.",
                                  cmCacheManager::INTERNAL);

There is once again a call to ConvertToUnixSlashes :(

Even if I put a call to :
         #if defined(_WIN32)
           cmSystemTools::CleanUpWindowsSlashes(cMakeSelf);
         #endif
before the first AddCacheDefinition, and if I surround the 
ConvertToUnixSlashes between  :
         #if !defined(_WIN32)
           cmSystemTools::ConvertToUnixSlashes(utilityExecutable);
         #endif
it fails, VTK_WRAP_TCL_EXE still uses '/'.

Why , Guess what, there is *another* call to ConvertToUnixSlashes in 
cmCacheManager::AddCacheEntry:

   if(type == FILEPATH || type == PATH)
     {
     cmSystemTools::ConvertToUnixSlashes(e.m_Value);
     }

so basically, I'm stuck again.

Well at this point I guess I can just modify it with :

   if(type == FILEPATH || type == PATH)
     {
#if defined(_WIN32)
     cmSystemTools::CleanUpWindowsSlashes(e.m_Value);
#else
     cmSystemTools::ConvertToUnixSlashes(e.m_Value);
#endif
     }

and it works, the value uses '\' in the cache... but it fails again !, the 
correct value does not make its way to the DSP files :( It's OK in the 
cache, but vtkWrapTcl.exe still use '/' in the DSP !

So I guess it has something to do with cmDSPWriter::WriteDSPFile(), but I 
was unable to find how : there is definitely a side-effect here, 
ConvertToUnixSlashes is called indirectly by some other functions.

What do the gurus think ?

>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!)

A 'cmSystemTools::JoinPath()' or even a static member var holding the 
'glue' element ('/' or '\') might probably have adressed some issues, but 
it's getting more difficult every day to spot the place where it has been 
hardcoded...