| [cdt-dev] Re-using CDT to support other statically typed object oriented language |
|
Hi Folks, I have a statically typed, object oriented language that
also uses the C preprocessor (UNO IDL, the IDL of the component framework
coming with OpenOffice). I started with the language extension point. A basic parser
creating the AST part is up and running, which enables the AST-based
functionality already. So, thanks to you folks, I have a great editor with header
file navigation, outline view, include browser, … almost for free (with
almost not using any internal API of CDT:-). This is really cool! Now I’m getting greedy: I want to turn on the
index-based functionality as well. I was having a look and see 2 basic strategies to get myself
hooked up with the PDOM: A) The UNO IDL AST nodes can completely be mapped to the ICPPAST*
tree without conflicts or “bending” their meaning, so far. So I let
the PDOMCPPLinkage create the PDOM nodes. -> little effort. B) - larger effort. - need to sub-class PDOMLinkage and PDOMBindung, which
creates lot more dependencies to internal CDT API. I decided for A). Here my questions: 1) I have seen
that there were already prototypes for other languages (e.g. C#) in the CDT. Can
anybody advice an ‘official’ way? 2) Is the
PDOMCPPLinkage depending on any CPP AST implementation classes? Then strategy
A) wouldn’t work. By now I couldn’t see I reason why it shouldn’t
work. 3) Should I
create bugzilla entries that would enhance the CDT to support other statically
typed languages (in my view the CDT somehow is the counterpart to the DLTK,
which is the platform for dynamically typed languages). I could at least create
a list of interfaces that should be moved to public CDT packages. Any advice is welcome. Greetings, Jens Elmenthaler. Jens Elmenthaler Architecture Development Team
WEEE-Reg.-Nr. DE 16968742 |
