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 Eclipse.org, 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.
Cheers,
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