<table><tr><td style="">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>I've kept the request to add a unittest to this in the back of my mind. I cannot think of any feasible way to do this.</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">The canonicalisation itself uses an external function</li>
<li class="remarkup-list-item">if it makes the cmake project import fail this will be caught by existing unittests</li>
</ul>

<p>In addition:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">it is not the import of projects affected by the use of a build.dir with symlink(s) in its path that goes awry: the project is imported correctly (and faithfully enough to reproduce a symptom that exists outside of KDevelop)</li>
<li class="remarkup-list-item">the issue manifests itself during parsing but is not the result of an issue in how KDevelop uses libclang to parse code</li>
</ul>

<p>In short, KDevelop triggers something that could be considered an issue in CMake and/or in Qt utilities like whatever generates the moc source files. The only thing KDevelop does wrong here is the fact that it doesn't protect the user against this situation.</p>

<p>The patch would undoubtedly be simpler if canonicalisation were done at the input level (i.e. when the user specifies a build directory) rather than on the fly each time the build.dir is obtained from the settings store. Doing this will also inform the user directly (and immediately, when the dir is obtained using a file dialog) what directory is used. I didn't dare to propose that change initially because of potential side-effects I cannot foresee but maybe such side-effects simply don't exist.</p>

<p>FWIW, some form of canonicalisation already happens when picking a build.dir. Otherwise one should get an error when selecting a build.dir path with symlinks in it for a project that was already configured for the canonical version of that path.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R32 KDevelop</div></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>To: </strong>rjvbb, KDevelop, apol<br /><strong>Cc: </strong>flherne, mwolff, apol, kdevelop-devel, geetamc, Pilzschaf, akshaydeo, surgenight, arrowdodger<br /></div>