Merging launch framework

[Niko Sams]

On Sun, Apr 26, 2009 at 9:20 PM, Andreas Pakulat <apaku at gmx.de> wrote:
> On 26.04.09 22:54:12, Vladimir Prus wrote:
>> On Sunday 26 April 2009 21:44:07 Andreas Pakulat wrote:
>> > Hi,
>> >
>> > good news, I've got the launch framework ready to execute applications and
>> > also configure launches. That means I could merge now.
Great News!
Though I'll miss that "Start (not yet working)" action :D

>> > However, I've also had to disable gdb plugin basically (i.e. it doesn't
>> > do anything at the moment) and I'm feeling kinda lost when trying to
>> > find out how I can properly port it to the launch framework.
that would not be good - as I'm currently working on the debugger.

>> Heh, I'm getting nervous about launch framework if its author does not know
>> how to make gdb work with it :-P
>
> Well, I know how to create a KJob that runs the app with gdb around it. My
> problem is trying to find the right place where to create the kjob and to
> know what other things need to be attached to it - debugsession,
> gdbcontroller, etc. Apart from that, gdb plugin currently knows about the
> gdb-job thats being executed and stores it internally.
>
>> > So I'd like some opinion on how we want to do the merging, should I just
>> > merge what I have and we'll try to port gdb together. Or should I just
>> > post a patch for current trunk (pretty huge diff however)?
>>
>> You probably should describe what problems you have with gdb. If these
>> are technical, then probably you can commit and I'll fixup gdb. If these
>> are fundamental, we probably resolve that before breaking trunk.
>
> I think its basically technical problems as I said above. I'm not sure
> where to create a job that reads all the config values to setup a KProcess
> and what I have to attach to that KProcess (input/output). Or what else I
> need to add to this process.
>
> I could probably find out all that myself, however that takes time, which
> means I'll have to constantly rebase the launch-framework branch against
> trunk updates. So if anybody can give me a short overview of what setup is
> done when the gdb "Start" action is executed that would speed up things a
> lot.
This is how it currently works:
CppDebuggerPlugin::execute (from IRunProvider) creates a new DebugSession
and sets the KJob to this DebugSession. So everytime the user clicks Start
a new DebugSession.
DebugSession::startProgram then calls GDBController::startProgram, that
calls GDBController::startDebugger where the gdb process is created
(GDB::start).

Also notice that there is just one GDBController instance across
multiple DebugSessions.
DebugSession was introduced by me for the generic debugger stuff. Long
term goal is
to move stuff from GDBController into DebugSession - as the current
design is a bit
complicated with this additional DebugSession level inbetween.
Additional benefit of
DebugSession is that it support multiple debug sessions.

If you think that design could be improved let me know.

Niko