[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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 agent
One 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.
Thanks,
Thomas
