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

[Andreas Pakulat]

> 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?
> 
> Michal Humpula wrote:
>     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).

That depends on your definition of 'mixing'. The instructions install KDevelop into a directory in your $HOME, making it as easy as rm -rf $HOME/kdevelop (or whatever you choose as install dir) to get rid of kdevelop. It does mix the the config settings, but these are per-app anyway so this only causes an issue if you use a version of the same app from your distro and that one has an issue understanding the configuration the newer version created. Same goes for temporary files.

But most KDE devs I know simply have no version of the app from their distro if they work on it, they want to use the one they hack on anyway to get the stuff they added 'asap' and want to make sure they 'eat their own dogfood'.

Anyway, my main interest was wether this obsoletes the 'debugging shell' setting in the gdb tab or not, i.e. wether that setting should just move to the native-app part of the config.


- Andreas


-----------------------------------------------------------
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/fa1de0b1/attachment.html>