[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] common launch configurations

this is a bit drastic and probably premature but instead of having DSF vs CDI shown to the user
we could have:
GDB 6.6 and higher vs older GDBs
where 6.6+ would go to DSF while older GDBs would go to CDI.
Of course, the gdb version would not be enforced, so we could always choose CDI or DSF;
it would provide some recommendation (maybe a bit too strong?) to the user.
Or, to be safer, we could use GDB 6.8 and higher.  I don't know how well CDI handles
6.8 right now, so maybe it is better to go for DSF in that case?
Heck, if we want to be really safe, if GDB 7.0 is out before Galieo, which is the current plan,
we could just have 7.0+ for DSF; I'm pretty sure CDI won't handle 7.0 as well as DSF.
I'm probably gonna regret this when the bugs start coming in :-)

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: Tuesday, February 17, 2009 3:45 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] common launch configurations

Using capabilities is a neat idea, though it suffers from the same problem as the UI in the launch dialog.  Users would still have to know what "DSF" means :-(

Sergey Prigogin wrote:
Before a comprehensive solution is developed, the problem can be partially alleviated by creating capabilities for CDT GNU Toolchain Debug Support and GDB DSF Debugger Integration. Even when both are installed, users should still be able to disable one or the other.


On Tue, Feb 17, 2009 at 11:45 AM, Pawel Piech <pawel.piech@xxxxxxxxxxxxx> wrote:
Hi All,
I've run into a new problem trying to create common launch configurations for CDT.  In short, I have the common launch configurations ready to be committed, but they present something of a new workflow challenge for users.  If a user installs both of the following optional features:
1) CDT GNU Toolchain Debug Support
2) GDB DSF Debugger Integration
he will be presented with the a launch configuration that requires him to choose a launcher (see attached screen caps). 

This problem could be avoided by creating a CDT product which could for the Eclipse C/C++ bundle, (instead of the standard Eclipse platform product used now).  I'm not really sure what would be other benefits or disadvantages of doing this, but it seems like a big change to satisfy this one problem. 

I'm looking for guidance on how big an issue this is for everyone and whether to commit the common launch configurations patch.  I also wonder what people think of defining a CDT product?


cdt-dev mailing list

_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/cdt-dev