Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] July Conf Call notable items

+1 from me :-)

Seriously though.  At least from the debugger point of view this makes a lot of sense. 

Doug Schaefer wrote:

Thanks Pawel,


Once you get one target integration done, there isn’t a whole lot of effort to move to a new one, relatively J. So having reusable components is the right strategy. And your strategy of creating platform-specific integrations is the direction I’d like to see us take for the CDT as whole.


Beyond stating that we have integrations with the GNU tools in the CDT you download from, we’ve never really stated what versions of those tools we actually integrate with. So users expect us to work with them all, even though we don’t get contributions to support them all.


The direction I’d like to see us move to is where all end users get their CDT from distributions. These distributions would either come with the toolchains they support, or list the toolchains they support. CDT for Windows is an example of such a distribution. The Linux distros almost all come with the CDT and I assume, or at least hope, that they are testing the CDT with the toolchains they deliver. And of course, most of the contributing vendors here deliver products with supported toolchains. And I think we as a community can create more as we get more contributions (e.g. Mac, different embedded GNU toolchains). For those brave enough, they can continue to download the CDT as they do today as well and set up their own integrations.


So, if we reach that goal, the statement about which debug framework is the default one becomes meaningless, since there is no default one, since there is no default toolchain support with the CDT.


That’s a pretty radical change, so please share your thoughts.



Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead,

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: Friday, July 06, 2007 12:31 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] July Conf Call notable items


Doug Schaefer wrote:

Mikhail K was interested in our plans for integrating DSF into the core CDT. I guess, in summary, my plan is to move the host development support to whichever framework works best and has the most contributors working on it. But the goal is to support both DSF and CDI and allow tools integrators to make the choice. And that includes ensuring the two play nicely together.


This brought up a question I have. Is anyone really working on making sure host development works? I did a lot of work in CDT 4 to make sure MinGW worked and to help Cygwin along. I will likely stop working on cygwin in the future since my efforts there will be on supporting the CDT for Windows distribution which is based on MinGW. I’m not sure anyone is working on making sure Linux tools integrations continue to work, although that is probably the easiest and we’ve been lucky enough that there aren’t many issues there. I do know we have a lot of issues on Mac OS X, which does make up a significant and growing part of our community. All of the committers are focused on making sure their commercial tools integrations continue to work, which they have all the right to. But how do we make sure the problems that the community is having with host development get addressed. Finding contributors with vested interest in these platforms would be the best approach. Linux should theoretically be easy, but I’ve almost given up hope for Windows, thus the CDT for Window distro to help focus effort there, and I have no idea about Mac…

We decided that for reference implementation of DSF that we will focus solely on the Linux platform running the latest version of GDB.  However, our intention is to make it possible to create platform-specific (and even version-specific) GDB integrations that mostly reuse common components, but which can be maintained independently from each other.  Hopefully this will make it easier for the community interested in a specific platform to take ownership of maintaining it, while keeping the core implementation free of strange legacy workarounds.



A reminder to register for the CDT Summit, where this debug issue will be likely front and center. We need to make sure we invite the Platform Debug team as well.


We continue to have no requests to branch off the CDT 4.0.1 work. Until we have one, HEAD will continue to be the 4.0.x stream.



Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead,



cdt-dev mailing list


_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx

Back to the top