Hi Pawel,
My questions was more about the debugger related UI
components (views and actions) we currently have in CDT and how these
components would coexist with DSF. My concern is that if DSF contributes similar
views and actions we will have duplicates which is definitely not a good
thing. What do you think?
Regards,
Mikhail
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.
Cheers Pawel
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.
Cheers,
Doug
Schaefer,
QNX
Software Systems Eclipse CDT Project Lead, http://cdtdoug.blogspot.com
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-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.
|