losing CMakeCache.txt after changing the compiler...

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

losing CMakeCache.txt after changing the compiler...

René J. V.  Bertin
Hi,

This happened once too often for me: I apply successive tweaks to a CMakeCache file, reinvoke make (or ninja) and then at some point lose everything because I forgot that changing the compiler is a "lethal" operation.

Why does cmake have to throw away the entire cache file when something changes in the compiler path? That seems like a cheap way to implement a "let's keep track of which cached settings depend on the choice of compiler". At the least it wouldn't be much less cheap to rename CMakeCache.txt to CMakeCache.bak instead of deleting it.

And FWIW, this is also a situation in which storing the exact CMake invocation in a comment at the top of the cache file could be useful...

R.
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: losing CMakeCache.txt after changing the compiler...

Marc CHEVRIER
You can easily avoid this bad experience by using different builds environments : one per compiler !
Le sam. 2 juin 2018 à 11:43, René J.V. Bertin <[hidden email]> a écrit :
Hi,

This happened once too often for me: I apply successive tweaks to a CMakeCache file, reinvoke make (or ninja) and then at some point lose everything because I forgot that changing the compiler is a "lethal" operation.

Why does cmake have to throw away the entire cache file when something changes in the compiler path? That seems like a cheap way to implement a "let's keep track of which cached settings depend on the choice of compiler". At the least it wouldn't be much less cheap to rename CMakeCache.txt to CMakeCache.bak instead of deleting it.

And FWIW, this is also a situation in which storing the exact CMake invocation in a comment at the top of the cache file could be useful...

R.
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: losing CMakeCache.txt after changing the compiler...

Hendrik Sattler
In reply to this post by René J. V. Bertin
Hi,

I also found that e.g. Qt Creator throws away the cache too eagerly, e.g. when  changing the deployment target IP address on the kit.

This led me to finding a solution for keeping command line definitions elsewhere because relying on the cache will hurt you bad sometimes.

Maybe more project-foreign people need to test cmake-enabled IDEs and ask for better behavior.

Otoh, cmake also should not rely that hard on its cache. When I upgrade the Qt installation and delete the old one, cmake fails hard where only a cmake expert can recover easily from. Why can't it check that cache file locations still exist when it runs?

When I upgrade gcc on linux, cmake doesn't notice at all, although almost all derived values are wrong at that point.

HS


Am 2. Juni 2018 11:43:02 MESZ schrieb "René J.V. Bertin" <[hidden email]>:

>Hi,
>
>This happened once too often for me: I apply successive tweaks to a
>CMakeCache file, reinvoke make (or ninja) and then at some point lose
>everything because I forgot that changing the compiler is a "lethal"
>operation.
>
>Why does cmake have to throw away the entire cache file when something
>changes in the compiler path? That seems like a cheap way to implement
>a "let's keep track of which cached settings depend on the choice of
>compiler". At the least it wouldn't be much less cheap to rename
>CMakeCache.txt to CMakeCache.bak instead of deleting it.
>
>And FWIW, this is also a situation in which storing the exact CMake
>invocation in a comment at the top of the cache file could be useful...
>
>R.
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: losing CMakeCache.txt after changing the compiler...

René J. V.  Bertin
In reply to this post by Marc CHEVRIER
Marc CHEVRIER wrote:

> You can easily avoid this bad experience by using different builds
> environments : one per compiler !


You mean one build directory per compiler? That can be very disk-expensive, and
it doesn't solve the issue (e.g. you clone an environment and then change the
compiler - why would that cause certain cached variables to be reset that don't
need to be reset).

Qt projects using CMake (e.g. KDE) are in a class of their own; Qt's auto-
generation applications use a mix of hardcoded absolute and relative paths that
can easily go wrong when you update something that invalidates certain paths.

Or when you access your build directory in different ways. This is a bit of a
different issue, but suppose you have directories:

/a/b/c/d/e/f/projectA/work/source
/a/b/c/d/e/f/projectA/work/build

and a symlink $HOME/projects/projectA -> /a/b/c/d/e/f/projectA

Depending on shell and OS you may get surprises when you do things like

%> cd $HOME/projects/
%> (cd projectA/work/build ; cmake ../source)
%> (cd /a/b/c/d/e/f/projectA/work/build ; make)

Qt's auto-generated relative paths (in step 2) will be invalid in step 3 if no
path normalisation occurs, because of the different number of levels between the
2 access paths to the same working directory. Linux suffers from this, not the
Mac OS.

This is a cmake issue only insofar as cmake could prevent it by normalising the
working dir always (make should probably do the same).

R.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: losing CMakeCache.txt after changing the compiler...

Marc CHEVRIER
By using multiple build environments, I mean multiple build directories as well as controlled environment for each of them.
If you have multiple compilers or even multiple versions of a compiler, by managing carefully environment variables (i.e. PATH variable for example) by using some bash functions, you can easily ensure to use always the correct compiler for each build environment.


Le mer. 6 juin 2018 à 16:50, René J. V. Bertin <[hidden email]> a écrit :
Marc CHEVRIER wrote:

> You can easily avoid this bad experience by using different builds
> environments : one per compiler !


You mean one build directory per compiler? That can be very disk-expensive, and
it doesn't solve the issue (e.g. you clone an environment and then change the
compiler - why would that cause certain cached variables to be reset that don't
need to be reset).

Qt projects using CMake (e.g. KDE) are in a class of their own; Qt's auto-
generation applications use a mix of hardcoded absolute and relative paths that
can easily go wrong when you update something that invalidates certain paths.

Or when you access your build directory in different ways. This is a bit of a
different issue, but suppose you have directories:

/a/b/c/d/e/f/projectA/work/source
/a/b/c/d/e/f/projectA/work/build

and a symlink $HOME/projects/projectA -> /a/b/c/d/e/f/projectA

Depending on shell and OS you may get surprises when you do things like

%> cd $HOME/projects/
%> (cd projectA/work/build ; cmake ../source)
%> (cd /a/b/c/d/e/f/projectA/work/build ; make)

Qt's auto-generated relative paths (in step 2) will be invalid in step 3 if no
path normalisation occurs, because of the different number of levels between the
2 access paths to the same working directory. Linux suffers from this, not the
Mac OS.

This is a cmake issue only insofar as cmake could prevent it by normalising the
working dir always (make should probably do the same).

R.

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: losing CMakeCache.txt after changing the compiler...

René J. V.  Bertin
Marc CHEVRIER wrote:

> If you have multiple compilers or even multiple versions of a compiler, by
> managing carefully environment variables (i.e. PATH variable for example)
> by using some bash functions, you can easily ensure to use always the
> correct compiler for each build environment.

That just shouldn't be necessary: to do this properly (in a way to helps
avoiding simple mistakes like running cmake with 1 env. setting and then make
with a different setting) requires writing something on top of cmake.

Not that I already have something like that, but did I say it shouldn't be
necessary?

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake