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
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 functio
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 -
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 projec
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 p
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 ch
