Re: [cdt-dev] ILinkage?

[James Blackburn <jamesblackburn@xxxxxxxxx>]

Hi Alex,

> An alternative would be to create a branch of CDT for the integration of
> Objective-C, and work off that. That might make the merging in easier if it
> were needed; but still doesn't help either the community or committer
> aspects to the problem.
> I'm also conscious that CDT committers have got other things on their plate
> right now with CDT 6.0 and would rather not be bugged by merge requests or a
> stream patches :-)

Another thing you could do is use one of these new-fangled DVCSs like
git :).  It really is great for keeping patchsets fresh and merging in
changes as and when.  I've also been in the situation of having far
too many branches to keep in sync - local builds and internal
releases, official eclipse cdt releases, experimental work, etc.. It's
a real nightmare with CVS.  Git allows you not to worry too much about
that stuff.  I've got a clone of the cdt-core cvs repository on
github:
http://github.com/jamesblackburn/cdt-core
I intend to sync this every day (the scripts which do this are also in
my github).  The CVS_* branches are the clean git cvsimport.  Do feel
free to fork this repository -- it'll save you the time of creating
the cvsimport at the very least.

Cheers,

James

> Once I'm a bit further down that path, and if it's progressing well, maybe
> we can look at that approach after CDT 6.0. I'm of course open to other
> ideas.
> Alex
> On 23 Feb 2009, at 09:38, Schorn, Markus wrote:
>
> 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.
>
>
> ________________________________
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Alex Blewitt
> Sent: Saturday, February 21, 2009 12:04 AM
> To: CDT General developers list.
> Cc: CDT General developers list.
> Subject: Re: [cdt-dev] ILinkage?
> Importance: Low
>
> 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
> On 20 Feb 2009, at 21:20, Mike Kucera <mkucera@xxxxxxxxxx> wrote:
>
> 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
>
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>