For ObjectiveC support you will need to provide a lot
of different pieces. I try to summarize what I can think
of
and hope that this is of some help for
you:
1)
An AST:
* You'll need to define all the interfaces
necessary to represent the syntax of Objective C. You
can probably
reuse the
interfaces for plain C and extend/add addtional ones as
requried.
* You need interfaces to
represent the bindings.
see packages:
org.eclipse.cdt.core.dom.ast,
org.eclipse.cdt.core.dom.ast.c
* You need an implementation for
the interfaces. Again you can probably reuse the implementation for
plain
C and add
what's needed. You will have to do your own IASTName, IASTTranslationUnit
and all the bindings
because these
interfaces return the linkage
they belong to.
see
packages: org.eclipse.cdt.internal.core.dom.parser,
org.eclipse.cdt.internal.core.dom.parser.c
2) A parser to create the
AST:
You probably want to reuse
CPreprocessor (you'll need some extensions) for preprocessing. To do
the
grammar you
have the choice between
extending the LR-parser for C or extending
AbstractGnuSourceCodeParser or
even GNUCSourceParser.
3) Semantics:
* Name resolution is started from
IASTName. You need to link your ast-names to the name-resolution
algorthms.
see:
CVisitor
4) Persistance:
* For your bindings you need two other
implementations: One for the pdom and one for the composite
index:
see packages
org.eclipse.cdt.internal.core.pdom.c,
org.eclipse.cdt.internal.core.index.composite.c
* Your implementation of ILinkage
in this context (extenstion to PDOMLinkage) will take care of mapping
bindings from the ast to
the index.
5) CModel:
You need to contribute a model builder
for Objective C or the existing model builder is extended to
handle
objective C,
also.
5) Editor:
Many editor features do not depend on
the ast, they use separate algorithms/scanners. I am not sure
whether the editor can be reused for
Objective C and what you need to do if it is possible, I am not an
expert
on this matter.
6) Refactoring:
As a minimum you would need to make
the rewriter work with the extensions introduced by Objective C.
You'll
have to check for each refactoring
whether it makes sense / works for Objective
C.
see
ASTWriter
expect that the refactoring code is
assuming
6) Other features: (content assist, search,
navigation, call-hierarchy, ...)
Many features are based on the ast and
the index and have a potential to work with Objective C.
However
you'll find linkage specific treatment
here or there (e.g. call-hierarchies between C and C++) and there
may
be a need to add some specific
treatment for Objective C.
In summary you will have to deal with a lot of
internals of CDT and therefore it makes sense to make ObjectiveC a part of
CDT. We will not be able to make CDT extensible such that you can add
Objective C via public API / extension points, only.
Markus.
Yeah, objective c is a superset of c and that's why I was hoping to
reuse/build upon what I could. However I'm still finding my way around the
packages and wonder how much of the .internal. is going to get in the way,
to the extent that I wonder if I'm going to have to reinvent the wheel in
any case.
Still, it's a good experiment and I'll submit what patches I can to
try and move things along, but I can't see how I can easily extend the
e.g. AbstractGNUSourceCodeParser or the KeywordSets if I needed to. And a
bigger concern is that given the PDOM isn't extendable externally coupled
with the fact that new types would be needed (protocols, selectors and so
forth) that probably makes it unlikely that autocomplete would work
without changes either.
What did you do when writing UPC? Did you just end up forking or
rewriting your own AST?
Alex
Sent from my (new) iPhone
I don't think its possible to add support for Objective-C without
making at least some minor enhancements to core CDT. For example Obj-C
adds the #import preprocessor directive. Support for that will probably
have to be added directly to CPreprocessor in CDT with a flag in
IScannerExtensionConfiguration to turn it on.
Alex, another
thing you may want to consider from the parsing side is using the LR C
parser as a base for Objective-C parsing. I used it as a base for
writing the UPC parser. I skimmed the apple docs and they say that
objective-c is fully compatible with C. So by reusing the LR C parser
you get a nice chunk of functionality for free including parsing the C
subset of the language and bindings to the CDT preprocessor. Its been
designed so that extending it to support new syntax should be easy (in
theory). This is just a thought worth considering, there may be good
reasons to write a parser from scratch, I'm not sure. And of course the
AST is a different story....
Mike Kucera
Software
Developer
IBM Eclipse CDT Team
mkucera@xxxxxxxxxx
<graycol.gif>Alex Blewitt ---02/20/2009 03:38:27 PM---I'll file an
enhancement but I thought the idea of doing objc dev outside of CDT HEAD
was to avoid any objc references until su
<ecblank.gif>
From: |
<ecblank.gif>
Alex Blewitt
<alex.blewitt@xxxxxxxxx> |
<ecblank.gif>
To: |
<ecblank.gif>
"CDT General
developers list." <cdt-dev@xxxxxxxxxxx> |
<ecblank.gif>
Cc: |
<ecblank.gif>
"CDT General developers list." <cdt-dev@xxxxxxxxxxx> |
<ecblank.gif>
Date: |
<ecblank.gif>
02/20/2009
03:38 PM |
<ecblank.gif>
Subject: |
<ecblank.gif>
Re: [cdt-dev]
ILinkage? |
I'll file an enhancement but I thought the idea
of doing objc dev outside of CDT HEAD was to avoid any objc references
until such time as it had built up momentum?A bigger concern, then, is what of the PDOM code which is all
.internal. (including some interfaces). Aren't the ILinkage and PDOM
fairly coupled? They appeared to be from my cursorary glancing.
Alex
Sent from my (new)
iPhone
On 20 Feb 2009, at 08:43, "Schorn,
Markus" <Markus.Schorn@xxxxxxxxxxxxx> wrote:
You cannot add a new linkage kind
from outside of CDT. The very basic reason for that is that
otherwise we cannot maintain unique integer constants for linkages.
If you need one for ObjectiveC, we'll add it to
ILinkage.
Please open an
enhancement request for it.
ILinkage is no longer marked as
experimental in 6.0. I don't expect AbstractCLikeLanguage to change
either.
If you use it, we
can also make it non-experimental (just open an enhancement
request).
Markus.
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
Alex Blewitt
Sent: Friday, February
20, 2009 2:43 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev]
ILinkage?
Importance: Low
I'm
starting to play around with the internals of CDT, and I've come
across the following whilst creating a subclass of
AbstractCLikeLanguage and the ILinkage that's referred to from it:
AbstractCLikeLanguage:
*
<strong>EXPERIMENTAL</strong>. This class or interface has been added as
* part of a work in progress. There is no guarantee that this API will work or
* that it will remain the same. Please do not use this API without consulting
* with the CDT team.
* @since 5.0
ILinkage.java
/**
* Represents a linkage in the AST or the index.
* <p>
* <strong>EXPERIMENTAL</strong>. This class or interface has been added as
* part of a work in progress. There is no guarantee that this API will
* work or that it will remain the same. Please do not use this API without
* consulting with the CDT team.
* </p>
* @since 4.0
*/
This seems to be defined as the
set {c,cpp,fortran} in the interface (and the implementing class is
internal). How would I go about setting up a name for Objective-C,
or can I simply return 'none' at this point? I'm somewhat playing in
the dark to get a feel of how it fits together right now, but given
that it had these in the comments I figured I'd do the honours.
However, given that CDT is working on 5.1 (at least, that's the
version it shows in Eclipse right now; 5.1.0.200902xxxx - will that
be bumped to 6.0 later?) I was wondering how experimental these
things are anyway ...
Alex
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
/u>
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________