Re: [CMake] losing CMakeCache.txt after changing the compiler...
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
Re: [CMake] losing CMakeCache.txt after changing the compiler...
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 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
Re: [CMake] losing CMakeCache.txt after changing the compiler...
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
Re: [CMake] losing CMakeCache.txt after changing the compiler...
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" : >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
Re: [CMake] losing CMakeCache.txt after changing the compiler...
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 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
