[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi!
The working groups will presumably be thinking about extension points when
they set up their 6 month plans and the right solution will come out. It is
hard to argue these things in generalities, better to get down to specifics
on specific cases.
Speaking of which, I'm going to drag us back to brass tacks on the
launcher. Why have a CDebugger/CDebuggerTab extension point set and not
have a similiar mechanism for the straight runs? Why is the debugger a
different case?
Thanks!
-Chris
At 07:32 PM 12/9/2002 -0500, you wrote:
>
> I'd like to weigh in on the side of extending via extension points and =
> not via extending or modifying classes. It's more work up front to =
> provide a nice flexible set of extension points but it would make it =
> easier for anyone using them and be much easier to maintain in the long =
> run.
Lets see this in different perspective(Eclipse pun intended):
The temptation is to use the extension points has a way to overload
a class or a behaviour then as a way to provide a __contribution__
to a plugin. The CEditor is a good example to illustrate, when we
started to work on it, we were "inspired"(sic) by the Java editor and if
we had our ways with the Java Editor, today it would have 200+ extension
points 8-). The Java editor had all the nice features and all we wanted
was to twist a little here a little there to enable the CEditor also ...
(un)fortunately we've been turn down flat with the promise that common
code will be refactor out and shared.
No one in this thread is proposing to add 200+ extensions
but it is easy to get carried away. The line is fuzzy when using
the xml extensions schema to add contributions/actions vs
overloading behaviours by placing extensions points.
I'm leery about the later where things starts to behave differently
with strange behaviour, because of certain plugin was enable or
disable.
This is my:
<extension id=opinion point=cdt.discussion>
<view id=myview/>
</extension>
> I've been following the CDT development in the hopes that we could =
> use it for development at SAS (most of our back end server stuff is in =
> C) but as it is now it's too hard and provides limited value.
>
CDT is still changing, so what are missing in the plugins to make this
less painfull ?
We need this kind of feedback to improve.
> For example, our build system is different from make, our proprietary =
> compiler gives different format errors from gcc, and gdb doesn't work =
> with our code - we have our own proprietary debugger (but we use native =
> object file formats). The extensibility isn't there for us to extend CDT =
> in any of these three areas as I'd like, for example to parse different =
> format errors and I was told to just change the CDT code, which I don't =
> want to do. (Besides the fact that I don't have the time to do that and =
> it would break or have to be remerged on every release, I feel it should =
> be modular and extendable enough to do that without editing the CDT =
> code.)
The code to contribute the error parsers is not in yet. But the future
work is to let the parsers be configurable per project. Say you
want the gcc-parser, and the make-parser or you want the watcom-parser
etc .. The UI pieces is not in place to do this.
At least for the first iteration, maybe we require something more
complexe/smart in the long run.
>
> Right now I've gone back to just using the Resource perspective, the =
> cbg.editor coloring tool, and using an external tool to do builds, and =
> forgetting about integrated debugging and error markers. That works as =
> far as it goes but isn't terribly integrated and nobody but me would =
> want to use it like this. So I'm eagerly awaiting new CDT functionality =
> that will support us better.
8-)
It is a question of resources, some work was done in this area, by
Sam Robb(I think) IMarkerGenerator.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
