[Qt-creator] Cross-debugging Win-Linux

[Andre Poenitz]

On Sun, Mar 06, 2011 at 01:05:01AM -0800, Patrick Masotta wrote:
> > 
> > Still a pretty unusual setup. Doesn't your Linux have X? 
> 
> unfortunatelly I dont have/cannot add X on my setup, that's why I'm
> cross-debugging...

Fair enough.
 
> > Anyway, there is nothing wrong with that per se, but maybe try to
> > understand that the focus is on more common or even "normal" setups.
> > And I'd go so far and call Windows->Linux crosscompilation and
> > debugging "normal" even if it's not well supported right now.
> 
> the pontential is right there I thing qt-creator should consider this
> scenario.

As I said: "I'd go so far and call [it] ... normal". That means I am
not opposed to the idea to support this scenario, either by providing
enough flexibility to make it work at all, or "properly", i.e. real
toolchain support similarly to the Maemo support.

Part 1 is achieved, after all you can add the paths to your .gdbinit,
and with a bit of gdb/python scripting even can be done in a way to
use per-binary search paths. Part 2 is a bit of work, sounds do-able
though. Feel free to do it and to create a merge request on gitorious.

> There are applications out there doing exactly the same thing as a
> VisualStudio Add-on; (WinGdb) it is a pay app + you  cannot use the VS
> express versions.

I see no problem with "(WinGdb) is a pay app", and similarly with
having to use VS proper when wanting to use Visual Studio. So it looks
like there are already solutions covering your use case, including tools
you are happy with.

> > You are abusing the tool. Start and Attach to Remote Application was
> > meant for "Let's have a quick look on what does this app on that
> > device", without the need to have a proper project. By deciding to
> > not use projects and sessions you are depriving yourself of the
> > possibility to use project information to start the debugger.
> >
> I think this does not make much sense; when you start a remote
> application,  you allways need: the debugger, the local app binary,
> the sysroot, the "sources", etc, etc. A bunch of info for every start,
> Can't you see that that info should come from a project file?

That's what I am proposing: "Real toolchain support". That's not
what you are using: "The attach-to-remote dialog".

> that dialog box has 7 fields and the missing current directory gives
> 8, there's nothing quick about a test that requieres a dialog box with
> 8 fields in order to run...

That's why it persists its contents. Trust me, this dialog does 
_exactly_ what it was meant for.
 
> > > > > 3) qt-creator does not save the breakpoints to the project file,
> > > > > it would be very handy saving them, if not I have to reset
> > > > > breakpoints every time I start a new debugging session....
> > > > 
> > > > Breakpoints are saved in the session. See
> > > > 
> > > > http://doc.qt.nokia.com/qtcreator-snapshot/creator-project-managing-sessions.html
> > 
> > > in my humble opinion I think the "sesion" file should be the project
> > > file itself, here Visual Studio does a good job. Why to split the
> > > project data on a project file and a "sesion" file
> > > independently handled??? I don't know, am I missing some point
> > > here?
> > 
> > Breakpoint data is not "project data".
> > 
> >
> > The project file is meant to be shared with colleagues and to be put
> > into revision control systems. That's not the place where _your_
> > breakpoints should go. Still you'd like to persist them for your own
> > convenience. That's what the sessions are for.
> 
> well, I respectfully disagree... if I have to share a project file I
> can (if I really want) strip breakpoints in just one command...

So we agree to disagree. Fine with me.

> >From an OO point of view I think IDE development should be project
> >file centered, the main "object" when I work on my IDE is the project
> >entity and I expect when I load/save my project, all the info related
> >to my interaction with the object "myProjectXXX" be stored "within"
> >the "object".... Splitting the concept of project and session on an
> >IDE app does not sound as good design to me.

Nobody forces you to accept this design, and you are certainly free to
design _your_ IDE anyway you want, including, perhaps, a full Visual
Studio clone.

Andre'