|Re: [cdt-dev] Launcher|
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
Back to the top