default debugger executables

[Aetf]

For the debugger executable config entry, if it's empty, the plugin will
use whatever comes first in PATH. (`gdb` for gdb plugin and `lldb-mi` for
lldb plugin). On my linux box (Archlinux), while lldb has version numbered
executables, there are also unversioned symlinks to latest version. Another
difference between OSX and linux llvm?

For duplicate menu entries. Actually I have thought about this problem for
a while. Currently both gdb and lldb plugin provides individual attach and
examine core actions, which don't read any configuration (because launch
configuration are per project target).

While I don't have a clear idea how this will be finally solved, I think
the first step to go is to having global launch configuration entry for
attach and examine core actions. This is already possible in gdb and lldb
plugin code to pass in a KConfigGroup object when attaching or examining
core. I'm just not familiar enough with the launch configuration system to
add global configurations.

The unsolved problem is, who is responsible for initializing the global
launch configuration in the first place, and adding menu actions to
KDevelop. Neither gdb nor lldb plugin is a good choice for this. And it is
too C/C++ specific to be added to kdevplatform.

Cheers,
Aetf

On Wed, Sep 14, 2016 at 12:44 PM René J.V. Bertin <rjvbertin at gmail.com>
wrote:

> On Wednesday September 14 2016 17:50:53 Aleix Pol wrote:
> > On Wed, Sep 14, 2016 at 9:35 AM, René J.V. Bertin <rjvbertin at gmail.com>
> wrote:
>
> >
> > IIRC the attach action is provided by the debug plugin itself..
>
> The action of attaching, indeed, yes. Maybe the widget to pick a process
> to attach to, too, but what difference does it make which KDevelop
> component provides the feature?
>
> BTW, I did notice 2 sets of entries in the Run menu on my Linux system
> where I have both plugins installed. It wouldn't really make sense if
> that's really because the gdb and lldb plugins both provide the same
> features. I'm not sure if and how you'd want to expose a debugger choice
> each time the user moves to debug an already running process, but
> presenting 2 identical menu items doesn't seem the way to go.
>
> R.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160914/dcee4bac/attachment.html>