Skip to main content

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


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

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.

I do like getting to set tab order in the suggested change. Perhaps we will move to that.

- How does the current launch delegate use the new information provided by these new

There are two launch extension points. One extends the LocalCLaunchDelegate, one adds tabs. The extension to the LocalCLaunchDelegate uses the information set into the ILaunchConfiguration by the tab extensions.

- What happens to any "Local C" launch configuration that where created before I installed the plugin that adds this new functionally to the "Local C" launching? Are they still valid?

The ILaunchConfiguration implementation of get routines has the user specify the default to use if the value is not present. While this case is unlikely for us, it does just work.

Does it just change the behavior of these launches (not
sure this is a good thing)?

In the case where the user already has a CDT project with launches they know the behavior is going to change. They have decided to move to a new processor. They know they are cross compiling. They are using new compilers. They are running in a simulator rather than native. This user is making a huge change and I believe that having things "just work with defaults" is ideal for this user given all else that they are facing.


Back to the top