[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] ObjectiveC

That's a tough question. Maybe you can work in a separate plugin and just use internals as you need with the
goal of moving the stuff into cdt at a later point (when there is some working functionality). Most of the ObjectiveC code should go in separate packages, anyways. It should not be necessary to change a lot of the current cdt source, so that modifications like that can be handled via bugzillas/patches.
 
To avoid license issues it would probably be good to start the developement within eclipse, so the work could
be done in a separate cdt-plugin, also.
 
Doug, can you give some advice on this?
 
Markus.
 

From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alex Blewitt
Sent: Tuesday, February 24, 2009 12:01 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] ILinkage?
Importance: Low

Markus,

Thanks, this is great information. I'm still learning my way through how CDT is structured (one disadvantage of a loosely coupled system is that it is harder to get used to from the outside!) but this will no doubt be a great benefit.

I'm beginning to share your thoughts on how easy it will be to re-use CDT via public APIs only without folding in to CDT. Ultimately, that's the end-goal of the objective c support anyway; but one concern raised was that we need to get some community behind ObjC before it can be folded in 'for real'. Add that to the fact that I'm not an Eclipse committer, and the fact that developing new code by patches is a death of a thousand cuts, and it made sense for me to kick-start this off in a separate area where the community effort could be judged and folded in at the right time. I'm not sure we're there yet.

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 :-)

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