RE: [cdt-debug-dev] GDB support in CDT

[Doug Schaefer <DSchaefer@xxxxxxx>]

The way things are going is to do yearly releases in June with two
maintenance releases in Sept and Feb. If you want new features or big bug
fixes, you need to get them in early in the release cycle, like now for CDT
4.0. If you are looking to patch a maintenance release then you only have a
few days left for CDT 3.1.1, or wait for CDT 3.1.2 in Feb.

We have a huge number of users of the CDT and a significant number of
vendors, who pay for most of CDT development, redistributing it. We need to
ensure the releases we put out are of a high quality. Rushing things will
make this difficult. We've done this in the past and have paid the price
dearly.

Doug Schaefer
QNX Software Systems
Eclipse CDT Project Lead
http://cdtdoug.blogspot.com
 

-----Original Message-----
From: cdt-debug-dev-bounces@xxxxxxxxxxx
[mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Mikhail Khodjaiants
Sent: Friday, September 01, 2006 8:26 AM
To: CDT Debug developers list
Subject: RE: [cdt-debug-dev] GDB support in CDT

>Does GDB have to be tied to CDT development cycles?

Currently, the trend is to synchronize the release dates of all Eclipse
projects. But it is up to community to decide. 
And again the problem with the bug fixing is the lack of resources. I
believe the current approach with mainteneance branches works fine, but the
cycles are too short.  

Cheers,
Mikhail
-----Original Message-----
From: cdt-debug-dev-bounces@xxxxxxxxxxx
[mailto:cdt-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Øyvind Harboe
Sent: 01 September 2006 12:25
To: cdt-debug-dev@xxxxxxxxxxx
Subject: [cdt-debug-dev] GDB support in CDT

>The gdb support IS in the separate plugins: 
>org.eclipse.cdt.debug.mi.core and org.eclipse.cdt.debug.mi.ui. There 
>are many companies that ship their
products based on
>this implementation. I believe they will find resources to support
the existing code.

The problem currently as I see it is that the GDB plugin is tied to the CDT
development project schedule. GDB support could do with much more rapid
cycles(stable releases 1/year'ish + snapshots for the brave monthly or so).
Hence my desire for splitting GDB support from CDT. In fact, I'd like to see
the GDB plugin 100% independent of CDT altogether(I'm not sure that there
exists concepts in Eclipse for supporting side-by-side installs of two
plugins using different underlying CDT versions).

Does GDB have to be tied to CDT development cycles?

I'm getting mixed messages from the CDT team on whether any further
development will take place on the GDB plugin. Feel free to clarify what the
consensus is on this one.

>By the way, switching to the new debug model (what you call the
WindRiver stuff) is not
>going to solve the current problems with the gdb implementation. It
is restiricted by the
>(in)abilities of gdb itself, not the model.

I'm not all hot and bothered about the WinDriver stuff. I just want bugfixes
to the existing stuff. It actually works pretty well.

>And by the way, there have been serious changes and additions in the
3.1 release - the
>support of custom command factories, more flexible launcher classes
to create custom
>launch configurations, not to mention your favorite verbose console mode.

Yup. Thanks!

--
Øyvind Harboe
http://www.zylin.com
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium.  Thank you.


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