RE: [cdt-debug-dev] StandAlone CDT debugger (was: Debugging native apps)

["Recoskie, Chris" <crecoskie@xxxxxx>]

I have to agree with some of the principles that Øyvind is putting forward, even if not all of his suggestions apply to TI's needs in particular at this moment.  It's not all just about speed.  We also run into the simplicity issue, just not in the same way as Øyvind.

We have definite use in general for perspectives, etc.  However, our current users are developing C and assembly programs for the MSP430, and if you start showing them things like the JDT, PDE, GNU toolchains, etc., they get very confused.  They have a hard time finding what they want to do, or end up thinking they can do things that they really can't ("What do you mean I can't create a Java program for the MSP430?  What is CygWin?  What do you mean I can't use GNU tools when they're shown right there as a new project option???").  Right now we actually strip out the JDT, PDE, and the GNU toolchain definitions for our product to avoid all these headaches.

Right now for an embedded developer to use Eclipse + CDT out of the box untouched you really have to be an Eclipse + CDT + GDB expert to be able to easily figure out what you're doing.  Many of our users barely know what GDB is let alone how to configure it properly for remote debugging.  Admittedly though,  a large part of the difficulty our users encounter has to do with the general usability level of Eclipse and that's a whole other kettle of fish :-P

Anyway... back to Øyvind's idea.  Right now we don't have a pressing need for a debugger-only flavour of CDT, but I can forsee some of our users wanting this out of our Eclipse based products in the future.  We have users of Code Composer Studio (our non-Eclipse product) that do all of their building remotely under ClearCase dynamic views on an shared Solaris box, do all their editing using vi or emacs on the same Solaris box, and have a PC sitting at their desk which they do their debugging on.  All they care about when it comes to our tools is having a graphical debugger on the PC.  All they want to have to do is point the debugger at the executable file, and away they go.  They don't mind having to configure their hardware setup for the debugger once, or possibly setting up a few other global options like "halt at main", but after that they don't want any nonsense about projects or telling the debugger where their source files are (since this is contained already in the relative path info stored in the debug information), or anything else.  Literally they want to click Debug, browse to an executable file, and that's it;  their project is loaded on their hardware and run on the remote target.

Personally for us (i.e. TI) in particular I don't think the debugger-only issue is a super critical issue... it's more of a "nice to have someday" type of thing in our minds, and we will always have a need for a full-fledged IDE.  It is however a valid usage model that many people will want to pursue.

___________________________________________
 
Chris Recoskie
Software Designer
IDE Frameworks Group
Texas Instruments, Toronto
 
 

> -----Original Message-----
> From: cdt-debug-dev-admin@xxxxxxxxxxx [mailto:cdt-debug-dev-
> admin@xxxxxxxxxxx] On Behalf Of Øyvind Harboe
> Sent: Thursday, January 06, 2005 12:23 PM
> To: cdt-debug-dev@xxxxxxxxxxx
> Subject: [cdt-debug-dev] StandAlone CDT debugger (was: Debugging native
> apps)
> 
> > Problems:
> > -  CDT/Debug lies on top of the Eclipse/Debug platform, which will pull
> in JFace, Eclipse/UI,
> > Workbench and all ... CDT/Debug depends also on CDT/{Core, UI}(use of
> the AST parser and the binary parser).
> > So it is still "heavy" ...
> 
> I wasn't referring to performance when I say "strip down Eclipse".
> 
> I want to reduce the number of concepts that are introduced "just to do
> debugging".
> 
> There is e.g. no need to explain the user what an "Eclipse Perspective"
> is. Ditto for "Eclipse Project".
> 
> > - Glossing over the need to create a workspace(IFile and all) on the
> fly.
> 
> Trivial once solved. :-)
> 
> > Maybe I'm wrong, but I always have the impression that if Eclipse could
> start within 2 seconds
> > we would not have this exchange 8-).
> 
> I don't think so.
> 
> If I believed that, I wouldn't have suggested a standalone debugger in
> the first place.
> 
> > Visual Studio can start within 2 seconds and I do not see/hear any
> requests for "stand-alone" versions.
> 
> Not on my machine. It has a mere 3GHz HT 768MByte RAM, so thats
> understandable... :-)
> 
> > I have to agree about improving the ease of use, whether with better
> support autoconf/automake or
> > better/simpler integration etc ..
> >
> > Meanwhile, users can:
> >   - create a project(std make), change the default location to point to
> the executable and .. debug.
> >   - or using an existing project, use linked folder/file
> 
> There is no "meanwhile" for Eclipse here.
> 
> It is Insight *until* this is in place.
> 
> We are talking about users whose *primary* working environment is bash.
> 
> Eclipse will never make bash obsolete. Just like the GDB console,
> Eclipse should embrace bash.
> 
> Make Eclipse available to bash users on their own terms. Ditto for
> "Eclipse Projects" vs. existing makefile systems.
> 
> Eclipse is the detour. It should introduce the minimum number of
> concepts and additional reading to get the job done.
> 
> "They can put men on the moon, but they can't launch the CDT debugger
> from bash" :-)
> 
> Ditto for standalone Eclipse CVS GUI btw.
> 
> --
> Øyvind Harboe
> http://www.zylin.com
> 
> 
> _______________________________________________
> cdt-debug-dev mailing list
> cdt-debug-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-debug-dev