<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="http://git.reviewboard.kde.org/r/114139/">http://git.reviewboard.kde.org/r/114139/</a>
</td>
</tr>
</table>
<br />
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">KDevelop already allows to setup environments for launching applications, the run of kbuildsycoca is not needed before every start of the application.
Also there is no such thing as an 'official' way to build KDE apps, the tutorial just shows one and happens to be hosted on KDE infrastructure. There are several other ways to hack on KDE apps, including such that don't require any temporary fiddling with the environment (see the KDevelop build instructions for example).
I guess the use-case here is that you want the same config being able to run your binary through the shell wrapper and with gdb right? In that case I'd say it would be better to move the setting from the gdb page to the native-app config. That is, add the setting as you have but make the gdb plugin use that setting for its 'debugging shell' field instead of duplicating the functionality there. It is a duplicate if I understand things correctly, right?</pre>
<br />
<p>- Andreas Pakulat</p>
<br />
<p>On November 26th, 2013, 1:41 p.m. UTC, Michal Humpula wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://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 KDevelop.</div>
<div>By Michal Humpula.</div>
<p style="color: grey;"><i>Updated Nov. 26, 2013, 1:41 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kdevplatform
</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;">Considering this document http://techbase.kde.org/Development/Tutorials/Building_An_Existing_Application, the official way to hack on the KDE apps is to setup separate environment and make install the application you are working on there. Currently you can specify an executable path in KDE launchers. That exe path can be path to shell script, that launches the app in/from correct env. But if you fill the shell script there instead of binary, you can't run a gdb against it.
So inspired by the similar option in gdb settings, this patch adds a shell option that NativeApp uses as launcher for the actual app.
There still might be the correct way to setup the launchers and honor the techbase document above, but I didn't find it. Suggestions welcomed.</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>plugins/execute/executeplugin.h <span style="color: grey">(acf9d51)</span></li>
<li>plugins/execute/executeplugin.cpp <span style="color: grey">(d3dd882)</span></li>
<li>plugins/execute/iexecuteplugin.h <span style="color: grey">(3ac3a37)</span></li>
<li>plugins/execute/nativeappconfig.cpp <span style="color: grey">(6f2dd8c)</span></li>
<li>plugins/execute/nativeappconfig.ui <span style="color: grey">(63954d3)</span></li>
<li>plugins/execute/nativeappjob.cpp <span style="color: grey">(4987e35)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/114139/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>