<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/117016/">https://git.reviewboard.kde.org/r/117016/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On April 12th, 2014, 10:48 a.m. UTC, <b>Alex Merry</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">This is my preferred solution, and is hopefully only a temporary one. However, I know David Faure doesn't like it, and (I assume) would rather have a generic LIBEXEC variable.
My view is that libexec should be used for stuff that's really internal to a piece of software (like a framework), and so a libexec env var shouldn't be necessary (except maybe for relocatability?), but the current situation with drkonqi should hopefully be a temporary one (until 5.1 or something), and so a specific var for unusual situations is reasonable.
However, given that an objection has already been raised by the maintainer, I'm not willing to give it a ship-it without his agreement.</pre>
</blockquote>
<p>On April 24th, 2014, 10:17 p.m. UTC, <b>David Faure</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I maintain my objection: while this particular issue might be temporary, the fact that libexec path gets hardcoded into the compiled library makes things impossible to relocate. PATH and LD_LIBRARY_PATH solve this for normal executables and libraries, an equivalent is just missing for libexec.
My suggestion then is more precisely: QFile::decodeName(qgetenv("LIBEXEC_PATH")).split(':') and pass that list to QStandardPaths::findExecutable(), which can take a list of paths to check into, as the second argument. Nice and easy. And later we can do the same in all frameworks that look for something in libexec (with a fallback to the builtin path).
</pre>
</blockquote>
<p>On April 30th, 2014, 12:04 p.m. UTC, <b>Alex Merry</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Dan: could you submit another version using David's suggested approach, please?</pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Dan? Any news?</pre>
<br />
<p>- Kevin</p>
<br />
<p>On April 9th, 2014, 8:47 a.m. UTC, Dan Vrátil wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for KDE Frameworks.</div>
<div>By Dan Vrátil.</div>
<p style="color: grey;"><i>Updated April 9, 2014, 8:47 a.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kcrash
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility.
This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance.</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">- Installed KCrash into /usr prefix
- Installed drkonqi from kde-runtime master to /opt/kde5 prefix
- started broken application
- no "could not find drkonqi" warning anymore
- crashed application, got drkonqi window</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>src/kcrash.cpp <span style="color: grey">(87163cc)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/117016/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>