Review Request 114139: plugin/execute: add option to start app in specific shell

[Michal Humpula]

> On Nov. 26, 2013, 6:11 p.m., Andreas Pakulat wrote:
> > 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?

The environments settings, last time I've tried, doesn't allow shell expansion, e.g. something like "PATH=$PATH:/kde_install/bin" is not possible. But, yes, I was thinking about giving up and expanding the whole thing and have it static.

If I read correctly, the HowToCompile for kdevelop mixes the system installation with user one. Though somebody on the IRC told me he is using that (and is happy with it), I don't find it to be plausible.

I wouldn't mix those two shells. Strictly speaking, if we agree that correct solution would be to fill the environment config, I might post a patch for easier filling that one instead (filling one by one is so slow).


- Michal


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/114139/#review44525
-----------------------------------------------------------


On Nov. 26, 2013, 1:41 p.m., Michal Humpula wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/114139/
> -----------------------------------------------------------
> 
> (Updated Nov. 26, 2013, 1:41 p.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdevplatform
> 
> 
> Description
> -------
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   plugins/execute/executeplugin.h acf9d51 
>   plugins/execute/executeplugin.cpp d3dd882 
>   plugins/execute/iexecuteplugin.h 3ac3a37 
>   plugins/execute/nativeappconfig.cpp 6f2dd8c 
>   plugins/execute/nativeappconfig.ui 63954d3 
>   plugins/execute/nativeappjob.cpp 4987e35 
> 
> Diff: http://git.reviewboard.kde.org/r/114139/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Michal Humpula
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20131126/c054727f/attachment.html>