<table><tr><td style="">rjvbb updated this revision to Diff 19767.<br />rjvbb added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D7930" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>It wasn't clear if you wanted to add a method to CMake or to KDevelop::Path so I went with the former which I find gives more readable code.</p>

<p>Why is this needed? Did you read the commit message of Milian's commit I referenced?</p>

<p>Take a working dir that's somewhere hidden behind a long access path (like what Linux will give to auto-mounted external drives), let's assume that you're using an out-of-source build approach where the source dir and the build dir live under a same parent. (Not crucial for the argument but I just work that way.)</p>

<p>You do the initial cmake run using the actual path, and then at some point you get tired of typing the long path so you create a symlink from a regular work directory under your $HOME to that working dir on the external.</p>

<p>KDevelop's build tree will contain auto-generated files that include headerfiles with paths like ../../../kdevelop-source/kdevplatform/interfaces which are representative for the actual locations on disk. Accessing that build directory via <tt style="background: #ebebeb; font-size: 13px;">(cd link-to-work/build ; make)</tt> will lead to all kinds of failures if make (and thus potentially cmake) finds itself executing under <tt style="background: #ebebeb; font-size: 13px;">/home/joe/work/coding/link-to-work/build</tt> instead of something like <tt style="background: #ebebeb; font-size: 13px;">/media/joe/JoesExternal/coding/KDE/KDevelop/build</tt>. Headerfiles expected under relative paths may not longer be found.</p>

<p>It's taken me a few days to realise why I kept getting those non-canonical shortcut paths in my compile commands after I rewrote my wrapper scripts to use canonical paths</p>

<p>There's another argument why this is a good idea: cross-platform consistency. On Mac it's impossible to avoid path normalisation and there may be other platforms where this is true too.</p></div></div><br /><div><strong>CHANGES SINCE LAST UPDATE</strong><div><a href="https://phabricator.kde.org/D7930?vs=19763&id=19767" rel="noreferrer">https://phabricator.kde.org/D7930?vs=19763&id=19767</a></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D7930" rel="noreferrer">https://phabricator.kde.org/D7930</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>plugins/cmake/cmakecommitchangesjob.cpp<br />
plugins/cmake/cmakeimportjsonjob.cpp<br />
plugins/cmake/cmakemanager.cpp<br />
plugins/cmake/cmakemodelitems.cpp<br />
plugins/cmake/cmakeserverimportjob.cpp<br />
plugins/cmake/cmakeutils.cpp<br />
plugins/cmake/cmakeutils.h<br />
plugins/cmake/settings/cmakepreferences.cpp</div></div></div><br /><div><strong>To: </strong>rjvbb, KDevelop, apol<br /><strong>Cc: </strong>apol, kdevelop-devel, geetamc, Pilzschaf, akshaydeo, surgenight, arrowdodger<br /></div>