Hi Russell,
Thanks for tracking this down to such a specific set of conditions.
If you hadn't done that work up front it might have taken a while to
find this.
Russell Yanofsky wrote:
> I think a safe and straightforward fix would be to make cmake use
> SystemTools::CollapseFullPath for the path
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
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
n
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
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
(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.)
Sim
