<div dir="ltr">By using multiple build environments, I mean multiple build directories as well as controlled environment for each of them.<div>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.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">Le mer. 6 juin 2018 à 16:50, René J. V.  Bertin <<a href="mailto:rjvbertin@gmail.com">rjvbertin@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Marc CHEVRIER wrote:<br>
<br>
> You can easily avoid this bad experience by using different builds<br>
> environments : one per compiler !<br>
<br>
<br>
You mean one build directory per compiler? That can be very disk-expensive, and <br>
it doesn't solve the issue (e.g. you clone an environment and then change the <br>
compiler - why would that cause certain cached variables to be reset that don't <br>
need to be reset).<br>
<br>
Qt projects using CMake (e.g. KDE) are in a class of their own; Qt's auto-<br>
generation applications use a mix of hardcoded absolute and relative paths that <br>
can easily go wrong when you update something that invalidates certain paths.<br>
<br>
Or when you access your build directory in different ways. This is a bit of a <br>
different issue, but suppose you have directories:<br>
<br>
/a/b/c/d/e/f/projectA/work/source<br>
/a/b/c/d/e/f/projectA/work/build<br>
<br>
and a symlink $HOME/projects/projectA -> /a/b/c/d/e/f/projectA<br>
<br>
Depending on shell and OS you may get surprises when you do things like<br>
<br>
%> cd $HOME/projects/<br>
%> (cd projectA/work/build ; cmake ../source)<br>
%> (cd /a/b/c/d/e/f/projectA/work/build ; make)<br>
<br>
Qt's auto-generated relative paths (in step 2) will be invalid in step 3 if no <br>
path normalisation occurs, because of the different number of levels between the <br>
2 access paths to the same working directory. Linux suffers from this, not the <br>
Mac OS.<br>
<br>
This is a cmake issue only insofar as cmake could prevent it by normalising the <br>
working dir always (make should probably do the same).<br>
<br>
R.<br>
<br>
-- <br>
<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Please keep messages on-topic and check the CMake FAQ at: <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMake_FAQ</a><br>
<br>
Kitware offers various services to support the CMake community. For more information on each offering, please visit:<br>
<br>
CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/support.html</a><br>
CMake Consulting: <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/consulting.html</a><br>
CMake Training Courses: <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/training.html</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://cmake.org/mailman/listinfo/cmake" rel="noreferrer" target="_blank">https://cmake.org/mailman/listinfo/cmake</a><br>
</blockquote></div>