<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/D17858">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">Users shouldn't change the dependencies and expect things to work without a rebuild.</pre></div></blockquote>

<p>That is not at all the idea behind this patch. The goal is that you can apply minor compiler updates without having to rebuild.<br />
The modification only allows very specific changes to the install location, which should arise only as the result of a clang update.</p>

<p>I invite you to research the code to see for yourself where the string we're discussing here is used: only in a single location where libclang has to be told where to find its own private headers. I don't even have words for the idea that it could be normal or acceptable to require the rebuild of something as large as KDevelop is a single character changes in that one sad string. Yes, I know about ccache and other optimisations those of us who build KDevelop from source at least once a week can exploit. That's irrelevant for all the package maintainers of all the distributions out there who'd like to ship KDevelop with an up-to-date libclang (and probably the system copy) ... and the bandwidth used to download all those copies of the rebuilt packages.</p>

<p>The concern that the path format could change is legitimate but unless we already know that and how it will I'd say let's take that bridge when we get to it. Either way we'll most likely end up using the hardcoded string in that case because the chance that my patch serves up an inappropriate but existing path if the format changes must be homeopatically slim.</p>

<p>The env. variable that allows to override the builtin path can wreak much more havoc, maybe it should be removed too if you're so concerned about experimenting users and randomness?!</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/D17858">https://phabricator.kde.org/D17858</a></div></div><br /><div><strong>To: </strong>rjvbb, KDevelop, flherne<br /><strong>Cc: </strong>flherne, kdevelop-devel, glebaccon, hase, antismap, iodelay, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd<br /></div>