[CMake] losing CMakeCache.txt after changing the compiler...

René J. V. Bertin rjvbertin at gmail.com
Wed Jun 6 10:34:37 EDT 2018


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.



More information about the CMake mailing list