cmake deletes cache when source patch contains symlink to complier directory

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

cmake deletes cache when source patch contains symlink to complier directory

Russell Yanofsky
(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
Reply | Threaded
Open this post in threaded view
|

Re: cmake deletes cache when source patch contains symlink to complier directory

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

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: cmake deletes cache when source patch contains symlink to complier directory

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


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

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

_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

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


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: cmake deletes cache when source patch contains symlink to complier directory

Brad King
In reply to this post by Russell Yanofsky
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 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.

It's available through get_filename_component(), using the ABSOLUTE or
REALPATH modes.  Please try adding that to the determine-compiler code
to see if it fixes your problem.

Thanks,
-Brad
_______________________________________________
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