[CMake] cmake deletes cache when source patch contains symlink to complier directory

[Russell Yanofsky]

I would guess unresolving the symlinks could make the 
CMAKE_USE_RELATIVE_PATHS option work better, but in the normal case I
guess it shouldn't matter whether symlink or non-symlink paths are used.
I just think it's important for CMakeCache.txt and CMakeCCompiler.cmake
to use the same path.

- Russ

On Wed, 2009-11-25 at 18:27 +0100, Michael Wild wrote:
> What has me confused is WHY CMake even does this symlink-resolution.  
> IMHO it should never notice that /home/russ/test_symlink/bin/gcc even  
> exists.
> 
> 
> Michael
> 
> 
> On 25. Nov, 2009, at 18:22 , Russell Yanofsky wrote:
> 
> > Hi Michael,
> >
> > Thanks for trying this out. It wasn't too hard to debug after I  
> > noticed
> > the discrepancy in the CMake output. The simple explanation of the bug
> > is that when CMake runs, it writes the CMAKE_C_COMPILER value out to  
> > two
> > different files:
> >
> >   CMakeCache.txt
> >   CMakeFiles/CMakeCCompiler.cmake
> >
> > The problem is it writes out different paths to each file, because
> > SystemTools::CollapseFullPath is called on the first path and not the
> > second. I think a good fix would be to call CollapseFullPath on both
> > paths, but I'm not sure how to do this because CollapseFullPath is a  
> > C++
> > function, and the second file isn't generated by C++.
> >
> > - Russ
> >
> > On Wed, 2009-11-25 at 18:04 +0100, Michael Wild wrote:
> >> Hi Russ
> >>
> >> I can't claim to fully understand your explanation, but I tried your
> >> steps on Mac OS X 10.6 and CMake-2.8 and I can reproduce this error.
> >> Really, really weird stuff!
> >>
> >> Bet it took you quite some time, effort and nerves to track this one
> >> down...
> >>
> >> Michael
> >>
> >> On 25. Nov, 2009, at 17:35 , Russell Yanofsky wrote:
> >>
> >>> (I tried to create a Mantis bug, but Mantis won't let me log in, and
> >>> when I try to reset the password, I see "This account is protected.
> >>> You
> >>> are not allowed to access this until the account protection is
> >>> lifted."
> >>> I tried creating a completely new account, and I see the same  
> >>> message
> >>> with that.)
> >>>
> >>> Simple set of steps to reproduce this bug:
> >>>
> >>>       mkdir /usr/bug_test
> >>>       ln -s /usr test_symlink
> >>>       cd test_symlink/bug_test
> >>>       echo "project(test)" > CMakeLists.txt
> >>>       cmake -DCMAKE_C_COMPILER=/usr/bin/gcc .
> >>>       cmake .
> >>>
> >>> The bug is that the second CMake command outputs:
> >>>
> >>>       You have changed variables that require your cache to be
> >>>       deleted. Configure will be re-run and you may have to reset
> >>> some
> >>>       variables.
> >>>
> >>> This warning is invalid because no variables were changed, and it  
> >>> is a
> >>> problem because after CMake deletes the cache, the configuration can
> >>> be
> >>> hosed.
> >>>
> >>> The reason why for the warning and CMake deleting the cache on the
> >>> second invocation is that the first invocation incorrectly saves
> >>> different CMAKE_C_COMPILER paths to CMakeCache.txt and
> >>> CMakeFiles/CMakeCCompiler.cmake files. The CMakeCCompiler file has  
> >>> the
> >>> original path:
> >>>
> >>>       SET(CMAKE_C_COMPILER "/usr/bin/gcc")
> >>>
> >>> But the cache looks something like:
> >>>
> >>>       CMAKE_C_COMPILER:FILEPATH=/home/russ/test_symlink/bin/gcc
> >>>
> >>> The reason for the discrepency is that cache path gets transformed
> >>> with
> >>> the SystemTools::CollapseFullPath function, while the CCompiler path
> >>> uses the original path specified on the command line.
> >>>
> >>> This bug is difficult to work around because the
> >>> SystemTools::CollapseFullPath uses logic that resolves symlinks in
> >>> reverse, which is something that would require some path crawling
> >>> outside of CMake.
> >>>
> >>> I think a safe and straightforward fix would be to make cmake use
> >>> SystemTools::CollapseFullPath for the path it writes to
> >>> CMakeFiles/CMakeCCompiler.cmake, but I didn't see an obvious way of
> >>> implementing this, because the file is generated by CMake code, and
> >>> not
> >>> C++ code. I wonder if it makes sense to expose the CollapseFullPath
> >>> function to CMake scripts so CMake code can use it.
> >>>
> >>> This bug just started happening for me recently, after my project
> >>> layout
> >>> changed, but I tested with a few CMake versions and the behavior is
> >>> the
> >>> same in CMake 2.8.0, 2.6.4, 2.6.2, and 2.6.0.
> >>>
> >>> I do want to say thanks to CMake developers for making this powerful
> >>> and
> >>> well thought-out tool. I've had my share of learning experiences  
> >>> with
> >>> CMake but given complexity of what CMake does, I've been amazed to
> >>> never
> >>> have encountered any real bugs until now, and this bug just seems  
> >>> like
> >>> an unhandled corner case.
> >>>
> >>> - Russ
> >>>
> >>> _______________________________________________
> >>> Powered by www.kitware.com
> >>>
> >>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> >>>
> >>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
> >>>
> >>> Follow this link to subscribe/unsubscribe:
> >>> http://www.cmake.org/mailman/listinfo/cmake
> >>
> >
> >
>