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

[Michael Wild]

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