|Re: [cdt-dev] Launcher|
Chris Songer wrote:
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.
Absolutely ... and as more people start using CDT to extend and build their products we will slowly get more guidance on the appropriate locations for more extension points. As it stands now there are less than a handfull of people working to "sculpt" the CDT to their needs. The QNX (wearing the non-open source hat) IDE is one and you guys are another. We (open source hat back on now =;-) are _very_ happy to have you guys doing something which sounds to me (from your descriptions) to be conceptually very similar to the QNX
IDE so we should find out what needs might have been overlooked.
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?
Some of these scenarios have been thought about and considered. That of course doesn't mean that they have been fully explored and can't use improvement. More to the contrary, the CDT is a project which could be considered as a Just In Time Framework where there certainly is an over-riding "extensibility" concept, but at the end of the day the work being done will certainly be motivated to some extent by what is needed _right_now_ (the build framework is a good example =;-). For your concerns/questions above, lets take the object file example. Yes it is appreciated that we are going to need different binary parsers (hence Alain's initial work on a COFF proof of concept binary parser to see that it could co-exist with the ELF one), but to date you are the first to indicate that a general elf parser might not be suitable. In this case you should absolutely bring your changes and suggestions to the table where they can be discussed. Often I find that these discussions either result in the solution being rejected because there is already what seems to be something that meets the apparent needs already in place, or the solution gets improved by
further generalization and incorporated into the project.
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."
I think that it is definitely a case by case basis and that there isn't a blanket statement. The idea is to give vendors enough knobs to turn that they can get what they want done with a minimum amount of effort. That being said, the solutions have to play well with others. Extension points tend to end up being pervasive throughout the entire framework so things which are shared (ie the capability of a compiler, a debugger, a builder etc) and used by others (or being configured by others) end up there. Things which tend to be product specific tend to leverage the existing generic classes putting different restraints on them to make their own "thing".
Well that was a lot of typing. Perhaps we can discuss this in the call on Monday what the criteria are adding an extension point vs. replacement..For those still awake, here's the Launcher discussion:If you are writing your own launcher, what happens if there is a change in LocalCLaunchDelegate driven by changes in the CDT APIs or eclipse APIs? The abstract class handles changes to the tabs, but what happens if there is a change in the Abstract class that affects the LocalCLaunchDelegate? Perhaps the launcher is so lightweight that replacement makes sense, but my novice view says that extensions here can be cleaner than replacement if we can come up with the right interfaces.
[Misc. launch comments snipped]I think that you have hit the head on the nail with your last sentence there, creating a launcher from the default C launcher was designed to be a lightweight endeavour specifically because launching is _very_ product specific. If we take a look at the QNX case (only because I can't talk intelligently enough about the Tensillica case) perhaps
it can serve as a further discussion point.For QNX we have several different options for launching/debugging (hereafter just called launching) applications:
- Local self-hosted launching - Remote launching using a generic target agent - Remote launching using a serial agentOne approach would be to try and incorporate all of the above into the generic CDT launcher. The current CDT launcher provides the user with the ability to select and configure different debuggers with different capabilities based on an extension point mechanism. So now you would be adding to that a new extention point which would provide the "connectivity" mechanism (upload/download/control/...) which in all likely hood is going to be tied to the capabilities of the debugger (for example we can't use the target agent and the generic debugger). This would mean that you would now be selecting things in one panel and then having to change dependancies in another panel, and from a UI point of view this seemed to be doing more harm than good. Also the case of what happens when you start having several vendors in the same development environment which want to
provide their own facilities .... lots of tied dependancies.Since these dependancies are indeed tied it was decided that the cleanest way to accomadate this was to make it such that the CDT launcher was highly configurable and that adding the custom bits for your launcher would be easy and straighforward (ok maybe easy and not so straightforward =;-). This also modelled the Java scheme for launching workspaces. To this end the QNX IDE product has three launch configurations:
- CDT Default launch configuration for the local case (0 QNX specific work)- QNX Target Agent launch configuration (ties to definition of remote targets and other QNX IDE specifics)
- QNX Serial Agent launch configuration (ties to HW capabilities)These configurations filter the debugger (and other tools) based on its capabilities and then only present those valid options to the user. The user sees right away what it is that their launch configuration is using (from a connectivity point of view), and we have documented in our product the trade offs of certain launch mechanisms (Target Agent provides additional integration to the IDE that the others do not).
---Now this isn't meant to say that there shouldn't be more extention points, but is rather just the simple use case/case study we looked at to justify the current launch configuration design. What would be ideal would be if there was an IDE (GNUDE!) which served as a reference to try out and demonstrate some of these "vendor" specific types of decisions. I guess the more people we have like you guys Chris the better it will be to round out the "common vs uncommon" cases and have more discussion on the issues.
Back to the top