Community
Participate
Working Groups
CDT already works reasonably well for Objective-C (used on the Macintosh for Cocoa and on other platforms in GNUStep). However, adding a few enhancements would make this a first-class IDE for Objective-C development. Suggested enhancements: * Support for objective-c keywords and syntax (primarily [object message]; syntax). * Support for parsing @interface into class objects like C++. This would enable the class browser and searching abilities. I believe gdb already fully supports objective-c so debugging already works great under eclipse.
Setting Milestone to Future ... if there is enough interest (i.e. votes) I could see this happening at some point ... however there is more demand for VC++ right now ...
I am interested in contributing to a project to fully integrate the objective-c language in the CDT. How do I get started? (In reply to comment #1) > Setting Milestone to Future ... if there is enough interest (i.e. votes) I > could see this happening at some point ... however there is more demand for > VC++ right now ...
Hello, I am able to build Objective-C apps using CDT on Mac OS X using the Apple GCC 4.0.1 and using the standard make and manually writing my makefile . Can you please shed some more light on how you did this? (In reply to comment #0) > CDT already works reasonably well for Objective-C (used on the Macintosh for > Cocoa and on other platforms in GNUStep). However, adding a few enhancements > would make this a first-class IDE for Objective-C development. > > Suggested enhancements: > * Support for objective-c keywords and syntax (primarily [object message]; > syntax). > * Support for parsing @interface into class objects like C++. This would > enable the class browser and searching abilities. > > I believe gdb already fully supports objective-c so debugging already works > great under eclipse.
It's now possible to add new ILanguages to CDT and map them to content types. You would still need new AST constructs to handle the language though, as it's got things that are not in C or C++. You could probably look at the C99 preprocessor and parser that we contributed recently and start looking there as to how to contribute your own parser and ILanguage. You can probably reuse our preprocessor and parts of our C grammar to create your own parser. No one is currently looking at doing this, but we would welcome a contribution. Looks like a great idea for a Google Summer of Code project or the like.
Something I would really like to do is completely decouple the preprocessor from LPG and the C99 parser (right now its dependent on the token types generated by LPG). That way it could be reused on any token stream.
(In reply to comment #5) > Something I would really like to do is completely decouple the preprocessor > from LPG and the C99 parser (right now its dependent on the token types > generated by LPG). That way it could be reused on any token stream. Definitely. I'd like to be able to use it with ANTLR generated parsers too. BTW, ANTLR v3 release party is next Tuesday. I got an invite. Too bad I'm not in San Fran :)
(In reply to comment #6) > Definitely. I'd like to be able to use it with ANTLR generated parsers too. I've opened bug #187328 for this. Maybe the Safari and Photran people would find this useful as well.
(In reply to comment #1) > Setting Milestone to Future ... if there is enough interest (i.e. votes) Another vote for interest in extending CDT to support Objective-C. I'm also willing to contribute to the effort. I assume the right place to start would be to extend the CDT parser to support objective-c constructs.
Kind of new to both Eclipse and Objective C, but if there is anything I can do to help out building Objective C into Eclipse, please let me know.
Future means you commit to fix it in the Future. Inboxes can't make committments. Moving to '--'.
How many votes are needed to get this active?
(In reply to comment #11) > How many votes are needed to get this active? Votes are just meant to gauge community interest. None of the committers are currently able/willing to work on it as it doesn't intersect with their business interests. Hence the "helpwanted" tag. Someone from the community will have to step up and contribute.
(In reply to comment #11) > How many votes are needed to get this active? > In reality, it only takes one vote, someone who is willing to actually contribute the code. All those who vote and don't contribute, I'm not sure how they're expecting it to get done. If you want to vote, vote with your time or $$$'s.
Anyone willing to work on this? I could offer some help (thou'm only beginning at Obj-C), but I can't do all by myself.
Did someone made some preliminary work on this? What is the status of the work made by Mike Kucera and Doug Schaefer in 2007? I saw that Jim has offered help. I may also do some work as well as I am pretty confortable in both Java and Objective C. We might just need a project leader to distribute workload and fix milestones. We might also need help for architecture and analysis. Is there someone that could federate people to get this done?
What would be a reasonable small first step in making some progress?
(In reply to comment #16) > What would be a reasonable small first step in making some progress? > Since I had no replies, I started working something on my own. I wrote a very simple sintax highlight for the language but it does not use CDT in any way. That's, at least, a start. If it's a good start, I could post it later.
I'd suggest a quick not to the cdt-dev list letting people know what your are doing and ask any questions you may have. There has been zero work done on Objective-C support so this is all new. There are ways to add languages to the CDT and Mike K is the expert. But he's not copied on this bug.
I am curious about how much people are using ObjC outside of Apple's Cocoa framework - presumably any first attempts in Eclipse will focus on Objective-C itself, and not deal with Cocoa until later (if at all.)
(In reply to comment #19) > I am curious about how much people are using ObjC outside of Apple's Cocoa > framework - presumably any first attempts in Eclipse will focus on Objective-C > itself, and not deal with Cocoa until later (if at all.) > I've used Eclipse for Objective-C development under window with GNUStep (company's code base was formerly using OpenStep) Eclipse already works well for most parts on this, except I have to use the GDB command input window quite a bit for 'print-object'
(In reply to comment #19) > I am curious about how much people are using ObjC outside of Apple's Cocoa > framework - presumably any first attempts in Eclipse will focus on Objective-C > itself, and not deal with Cocoa until later (if at all.) We use ObjC quite a lot here, and we could use a good IDE that supports ObjC. Right now everyone uses their own text editor for code editing, Visual Studio for debugging and some other tools for searching the code. It's a mess. I'm experienced in both Java and Objective C so I might be of assistance to this feature request, however: I only have limited time available.
Is anyone interested in discussing this at EclipseCon in March? There's quite a lot in implementing a new language parser/indexer/complete etc. and I'd have zero time between now and then, but if we can get some conversations going and a bit of hackery in place, it would be good to see if we can add dribs and drabs in an incubator environment.
I've created http://code.google.com/p/objectiveclipse/ to start working on this; if anyone's interested in joining in, drop me a line.
I am interested in contributing to it . As I am new to Eclipse community. I may need some help to get it started . Thanks Ashwani Kumar
Probably best take this off-line; but there's a getting started page (http://code.google.com/p/objectiveclipse/wiki/GettingStarted) where you can download and compile what's in SVN so far, and a minimal list of issues (http://code.google.com/p/objectiveclipse/issues/list) that need to be addressed. Even thinking up new use cases for what the plugin should do would be helpful :-) The project page also lists the mailing lists for the project; I'd suggest you follow up questions to the objcetiveclipse-dev group (http://groups.google.com/group/objectiveclipse-dev)
(In reply to comment #25) > Probably best take this off-line; but there's a getting started page > (http://code.google.com/p/objectiveclipse/wiki/GettingStarted) ... The ObjectivEClipse project has been closed, through lack of interest and unable to refactor itself to work on top of CDT 7.0, due out later this month. The only real way to integrate a new language at the parser level, based upon the CDT C parser, is to do it at the CDT level. For example, the C refactoring for 7.0 was done with the knowledge and support of the C++ plugin at the same time. Objective-C support would have to be refactored at the same time in order to not break.
(In reply to comment #26) > (In reply to comment #25) > > Probably best take this off-line; but there's a getting started page > > (http://code.google.com/p/objectiveclipse/wiki/GettingStarted) ... > > The ObjectivEClipse project has been closed, through lack of interest and > unable to refactor itself to work on top of CDT 7.0, due out later this month. > > The only real way to integrate a new language at the parser level, based upon > the CDT C parser, is to do it at the CDT level. For example, the C refactoring > for 7.0 was done with the knowledge and support of the C++ plugin at the same > time. Objective-C support would have to be refactored at the same time in order > to not break. Thanks Alex. I'd like to use Objective-C as an example of how to add a language to CDT. My hope is that we can restructure the APIs for CDT 8.0 to make this easier.
(In reply to comment #27) > Thanks Alex. I'd like to use Objective-C as an example of how to add a language > to CDT. My hope is that we can restructure the APIs for CDT 8.0 to make this > easier. I think you'd be better off using a non-C language as an example, like C#, to demonstrate it. That would be easier to include, because then you'd be writing the parser from scratch in the first place. However, the key problem is hooking in to the parser's expression and declaration points, and the fact that the parser is all internal and friendly with the Ui: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-core/org.eclipse.cdt.core/parser/org/eclipse/cdt/internal/core/parser/?root=Tools_Project org.eclipse.cdt.internal.core.dom;x-friends:="org.eclipse.cdt.ui", org.eclipse.cdt.internal.core.dom.parser;x-friends:="org.eclipse.cdt.ui", org.eclipse.cdt.internal.core.dom.parser.c;x-friends:="org.eclipse.cdt.ui", org.eclipse.cdt.internal.core.dom.parser.cpp;x-friends:="org.eclipse.cdt.ui", org.eclipse.cdt.internal.core.dom.parser.cpp.semantics;x-friends:="org.eclipse.cdt.ui", The only way that Objective-C will realistically fit in is as a peer to cpp with the same friends restrictions (and that refactorings to the base are done in a context where the dependent languages are open as well). Doing it as an external project is ultimately futile, even if CDT moves to Git in the next release. Note that there are also other C level language features, like blocks, which are available outside of Objective-C and OSX and which really should be integrated at the C level, with some kind of option to enable/disable the use of blocks as appropriate.
(In reply to comment #28) > I think you'd be better off using a non-C language as an example, like C#, to > demonstrate it. That would be easier to include, because then you'd be writing > the parser from scratch in the first place. Ah, but I would be. I have a start of a parser written in ANTLR, starting with C and hope to add Objective- to it. My first look again at IASTTranslationUnit made me realize that there are a lot of assumptions built into the DOM, like the parser technology being used, that need to be broken.
BTW, I also looked at Xtext. Unfortunately they don't support semantic predicates which are necessary to parse C-like languages. There was word they would for Helios but I haven't seen confirmation of that.
(In reply to comment #29) > Ah, but I would be. I have a start of a parser written in ANTLR, starting with > C and hope to add Objective- to it. My first look again at IASTTranslationUnit > made me realize that there are a lot of assumptions built into the DOM, like > the parser technology being used, that need to be broken. There are some other self-limiting things which make it more difficult than it needs to be: * Duplication of Ixx types across the C and CPP variants: org/eclipse/cdt/core/dom/ast/IASTIfStatement.class org/eclipse/cdt/core/dom/ast/IASTPreprocessorIfStatement.class org/eclipse/cdt/core/dom/ast/cpp/ICPPASTIfStatement.class org/eclipse/cdt/internal/core/dom/parser/c/CASTIfStatement.class org/eclipse/cdt/internal/core/dom/parser/cpp/CPPASTIfStatement.class * There being no different 'base' CDT feature; all CDT-derived projects have a 'cnature' but it's considered C if it doesn't have a 'cppnature' and C++ if it does have a 'cppnature'. It would probably make sense if there were a base cdt feature, and then vanilla c could sit on top of that (and cpp sit on top of the base feature). We could then get rid of the ParserLanguage hack: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core/parser/org/eclipse/cdt/core/parser/ParserLanguage.java?revision=1.5&root=Tools_Project&view=markup * Storage of the PDOM being done on hard-coded enums which are only available in the CDT is pretty self-limiting (though I don't know if this is used any more? org/eclipse/cdt/internal/core/pdom/IPDOM) * Linkage defining a 'type' is hard-coded, instead of being picked up by an extension: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core/parser/org/eclipse/cdt/internal/core/dom/Linkage.java?revision=1.7&root=Tools_Project&view=markup Objective-C also has some other features (like the -frameworks extension on Apple's GCC) which affects the way that imports are parsed. I think that's tracked on a different bug.
I'd like to define a minimal IAST and IBinding hierarchy that enables the indexer and source navigation features to work. Since the C and C++ DOMs have different implementations, I'm not sure why we have such a huge overlap. e.g. Why is there an IASTIfStatement? (BTW, preprocessor if is for #if, it's very different). BTW, I've started a project at Eclipse Labs to hold this work: http://code.google.com/a/eclipselabs.org/p/cdtantlr
The other alternative is to use an existing external parser such as the Objective C parser that is available in libllvm. Given that Apple will soon move to using LLVM exclusively on the OS X platform there is probably a lot of reuse that can be gained from libllvm.
I doubt this will happen in the shape of CDT parser support given the amount of work needed and the diminishing amount of expertise that would be required to review proposed changes. Otherwise, an alternative would be to use Clangd which I believe has support for Objective-C. CDT already has a feature to integrate Clangd. A more specific bug could be created if there is anything missing in the Clangd integration.
