Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Launcher

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. 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.

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.)

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.

--Ed Burnette, www.sas.com



> Message: 1
> Date: Fri, 06 Dec 2002 10:30:25 -0800
> To: cdt-dev@xxxxxxxxxxx, cdt-dev@xxxxxxxxxxx
> From: Chris Songer <songer@xxxxxxxxxxxxx>
> Subject: Re: [cdt-dev] Launcher
> Reply-To: cdt-dev@xxxxxxxxxxx
> 
> Hi!
> 
> Before going into details on the good questions raised regarding the 
> launcher, I'm curious about a broader point.
> 
> My current view is that eclipse is compelling because no one 
> is telling 
> you: "write a new org.eclipse.debug.core.foo by using our 
> existing classes" 
> but instead the message is: "extend these things with our 
> well conceived 
> extension points to do what you want." I'm certainly not 
> contending that 
> the interfaces we used are the right extensions to the CDT. 
> But I do think 
> that the requirements we face at Tensilica are not beyond the 
> pale. Any 
> other cross-compilation CDTs are going to have the same issues.
> 
> Now perhaps that extension point method should not be the 
> modus operandi of 
> the CDT. But it makes me wonder: what happens if we need to add error 
> parsers because our compiler front ends are not exactly the 
> ones you all 
> are using? What happens if our object files are somewhat 
> different and need 
> a different elf reader? What if there is more information in 
> them and we 
> want to display additional things? What about our custom 
> assembly format? 
> What if our C is stylized in some cases?
> 
> That's not all of the questions, and today I don't care about 
> the specific 
> answers. But our development approach will be affected by whether the 
> answer tends to be "use what you can and replace the base 
> code with your 
> own stuff" or "we should find out how to do an extension point."
> 


Back to the top