<table><tr><td style="">mwolff 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/D17289">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D17289#429526" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D17289#429526</a>, <a href="https://phabricator.kde.org/p/rjvbb/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@rjvbb</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>And there are probably places where the simpler QProcess API was used<br />
 instead.</p></blockquote>

<p>But the KDevelop env. profiles are already based on or compatible with QProcess::setProcessEnvironment(), no?</p></div>
</blockquote>

<p>yes, but you actually have to use those profiles. And there are places where we don't do that, that's my point.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><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);">> Would it be feasible to reduce the footprint of this overhaul by using a wrapper around writableLocation(QSP::TempLocation) instead?

I don't see how that would change anything, considering we need to change TMPDIR for libclang, which isn't using Qt internally?</pre></div></blockquote>

<p>I think that what I had in mind was that replacing one function call with another could be easy and unique enough to do it with a global search/replace. I didn't write down the exact thought I had when I asked that question but it must have been for a wrapper with an appropriate default for a flag that indicates whether or not the original TMPDIR had to be used/replaced.</p></blockquote>

<p>It's not one function call, it's different ones. There are the static <tt style="background: #ebebeb; font-size: 13px;">[KQ]Process</tt> functions, then the non-static versions too.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><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);">You cannot, since env vars are process-wide and thus changing them from a background thread would lead to race conditions.</pre></div></blockquote>

<p>And that's going to remain a problem if there are places in KDevelop where you can only (re)set TMPDIR before spawning the child as opposed to changing the value in the child process (= between the fork() and the exec()).</p></blockquote>

<p>No, when you use QProcessEnvironment, then it won't mess with TMPDIR on the parent process.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>In short, we have only 2 alternative (to this here) approaches that don't require a huge overhaul:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">request some sort of libclang::setTmpDir() function (and hope it becomes available this lifetime)</li>
</ul></blockquote>

<p>I doubt they'll ever add that. We have much more useful features waiting in review limbo for a long time.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><ul class="remarkup-list">
<li class="remarkup-list-item">add an environment profile to be applied to KDevelop itself at startup, so that users can decide for themselves if they want to change TMPDIR to something specific that will then be applied to all processes spawned by KDevelop too. I have a local patch (rejected long ago) that applies the selected default profile and it's been working just fine for me.</li>
</ul></blockquote>

<p>Do it right, or don't do it.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Related question: shouldn't the environment profiles have one or all of these?</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">an option to clear the existing environment and apply only the variables set in the profile, possibly with a whitelist of variables to preserve</li>
</ul></blockquote>

<p>yes</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><ul class="remarkup-list">
<li class="remarkup-list-item">a list of variables to unset (if that's not already possible by leaving their value entry empty)</li>
</ul></blockquote>

<p>setting to empty should do it</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><ul class="remarkup-list">
<li class="remarkup-list-item">a list of variables to cache at startup along with syntax to use these cached values (probably relevant only if profile is applied at startup)</li>
</ul></blockquote>

<p>no, use a batch/bash script instead</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/D17289">https://phabricator.kde.org/D17289</a></div></div><br /><div><strong>To: </strong>rjvbb, KDevelop, kfunk, mwolff<br /><strong>Cc: </strong>aaronpuchert, mwolff, pino, kfunk, kdevelop-devel, gennad, glebaccon, domson, antismap, iodelay, alexeymin, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd<br /></div>