|
TimeSys so
far has managed to ship an unmodified Eclipse;
the last two
releases of our IDE have also managed to use
a largely
unmodified version of CDT as well, though we've
had to
make some accomidations in our code to adapt CDT
behavior to
our needs.
Our eventual
goal is to use a completely unmodified version
of CDT, with
all of our customizations being implemented via
CDT
extension points. We're not quite there yet, but with
each new
release of CDT, we've been able to implement more
and more of
our customizations via public APIs instead of
having to
depend on CDT implementation details.
-Samrobb
Intel has so far
shipped Eclipse and CDT unmodified for the reasons that have been
mentioned. We don’t require our users to use the CDT and Eclipse that we
provide on our kit. It is there as a convenience.
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lott, Jeremiah
Sent: Friday, July 22, 2005 11:02
AM
To: CDT General developers
list.
Subject: RE: [cdt-dev]
CDT 3.0 Closing
>
There will always be
some bug discovered by our internal QA that some project manager says
we
> must fix for
our product release, or some feature that our customers say they must have,
etc., and
> it’s very
difficult to just wait for the next CDT release for what you need and pitch
your own product
> schedule out
the window.
Just out of
curiosity, do you then test for compatibility with 3rd party
plugins? I've been OK with our procedure so far, but if no one else
is doing things this way, then we may be running a higher risk than
necessary. Plus if everyone else is modifying CDT, then our approach to
compatibility produces less benefit anyway, as no one else is actually using
the exact codebase we are using as our compatibility
criteria.
|
