[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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."
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
tabs?
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.
Thanks!
-Chris
