I am curious what changed that broke you. So far our API
tooling builds haven't been failing. If you're using something that's
currently internal, we should look at making it an official API.
Actually we're using a LOT of stuff that's currently internal... mainly
we subclass various classes from the CDT UI (or just reference the CDT
classes directly in plugin.xml) and change labels from "C/C++" to
"Fortran." I think there are a couple of classes we had to actually
copy and modify, but most of it's just subclassed with one or two
methods overridden. Anyway, the Fortran perspective, Fortran Projects
view, Fortran launch configuration and launch actions, project property
pages, etc. are all done this way.
All of this is in the org.eclipse.photran.cdtinterface project if you
want to look around, mainly in these packages and, of course, in its
nightmarish plugin.xml.
- org.eclipse.photran.internal.cdtinterface.ui
- org.eclipse.photran.internal.cdtinterface.launch
- org.eclipse.photran.internal.cdtinterface.ui.editor
I apologize in advance for what a horrible hack some of it is. The
refactoring engine and the parts of Photran I actually care about are
much better designed. I promise. :-) Eventually I'd like to figure
out the "right" way to do share some of this UI between CDT and
Photran, but so far the goal has been "just get it working without any
changes to CDT so you can focus on refactoring and writing a
dissertation."
So if you want to talk about making API for some of the things we're
trying to do, I'm completely open to it. In the cases where we're
doing something naughty but doing it "right" will require some
time-consuming, invasive change to CDT, we can continue hijacking your
internal classes and dealing with the consequences... no problem...
Jeff
|