Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] adding a new language to the CDT

Again, there's a lot of history and realities here.

LTK is dead. There are no further plans to evolve it. The existing IDE
teams at Eclipse appear to have been decimated. There are very few of us
left, at least in the full-time equivalent sense. The reality is, what
you see is pretty much all you're going to get unless we get a new
infusion of investment.

CDT is a clone of the JDT from 7 years ago. I'm sure you can still see
comments with "Java" in them. Just take a look at ICElement versus
IJavaElement, eerily similar. There's even some weirdness still left
behind like IPathEntry that originated in the JDT and never made real
sense to me in the C/C++ world.

As Markus stated earlier, a language provider still needs to provide
their own language model. Our "MOF" is very minimal. And don't disregard
the benefits of a reusable build and debug framework, which by the
nature of the environments we work in have always been language
independent. Gdb and gcc support many languages, and Make supports
building anything.

BTW, IMP is a really bad name, otherwise I would have remembered it,
like I did with Safari ;)

Cheers,
Doug.

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Tom Ball
> Sent: Tuesday, October 28, 2008 1:43 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] adding a new language to the CDT
> 
> Good luck implementing that vision, as it's a potential bog to avoid.
> IDEs need to model the languages they support, and the more 
> deeply you integrate specific language support into the IDE, 
> the more unique your language model needs to be. Why doesn't 
> CDT use JDT?  It has a lot to do with how different an 
> accurate Java model is from a good C++ model.
>  Anyone intrigued by the notion that a common model can be 
> created to support all languages should review how poorly MOF
> (http://www.omg.org/mof/) is used outside of a few UML tools. 
>  The tone of this response is a bit vehement because I had 
> the misfortune to work on a MOF-related project, which 
> eventually had to be put to sleep in spite of the hard work 
> of many very smart engineers.
> 
> It's very likely that CDT has valuable language-independent 
> technology, but the best approach (IMHO) is to extract that 
> code to a separate package which can be shared by other 
> languages without mixing
> language issues   Eclipse has already started that work with LTK, and
> my personal view is that time invested in that and similar 
> efforts will have a bigger payoff and lower risk of getting 
> stuck, especially as the number of supported languages increases.
> 
> NetBeans recently worked around this by providing a 
> lightweight common language framework 
> (http://wiki.netbeans.org/Schliemann), which language 
> implementors can invest different amounts of effort to get 
> different levels of integration.  I'm not saying that Eclipse 
> should do things the NetBeans-way (I want to see my next 
> birthday! :-), but it demonstrates the case for having a 
> common language integration framework which languages 
> independently extend, rather than one language extending another's.
> 
> Tom
> 
> On Tue, Oct 28, 2008 at 10:15 AM, Hilliard, Bill 
> <bill.hilliard@xxxxxxxxx> wrote:
> > Actually, there is a goal of making CDT extendible to 
> support multiple 
> > languages.  See the "Vision Statement" slides on the wiki from the 
> > Fall
> > 2005 CDT summit.  Also, see the Eclipse technology Photran project 
> > which builds a Fortran IDE over CDT.  In Addition, Doug S. has 
> > commented in the past about his efforts to build an Ada 
> support package over CDT.
> > Jeff Overbey of the Photran project wrote a white paper 
> about adapting 
> > CDT to other languages.  You might see if that has helpful 
> information 
> > for you.
> >
> > Bill
> >
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> > On Behalf Of Tom Ball
> > Sent: Tuesday, October 28, 2008 12:45 PM
> > To: CDT General developers list.
> > Subject: Re: [cdt-dev] adding a new language to the CDT
> >
> > I'm not a CDT expert, but what you describe seems like a backwards
> > approach:  JDT and CDT are purposely specific to their respective 
> > languages, so new languages should have their own specific 
> IDE support 
> > rather than warp another language's.  There are several Eclipse 
> > plug-in API packages to make this easier, such as LTK which 
> provides 
> > common refactoring support.  My suggestion is to write separate IDE 
> > support for your language, but use CDT and JDT as best-of-class 
> > example code.
> >
> > Tom
> >
> > On Tue, Oct 28, 2008 at 6:14 AM, Michael Rosenfelder 
> > <MROSENFE@xxxxxxxxxx> wrote:
> >>
> >> Hi,
> >> I'm working on an Eclipse Plug-In to support a procedural 
> programming 
> >> language called PL8, a PL/I variant for systems 
> programming. We have
> > PL8 and
> >> C source files in one source tree (project). Our compiler 
> builds all
> > files
> >> to object files and then they are linked together to one 
> binary. It 
> >> is possible to call a C-function from a PL8-function and 
> vice versa. 
> >> So
> > our
> >> idea was to use the CDT and treat the source tree as a 
> C/C++ project.
> > The
> >> C/C++ files will be handled by CDT and the PL8 files are 
> handled by a
> > PL8
> >> editor (Syntax highlighting, outline view). We also want to use the
> > code
> >> navigation feature in the PL8 context. Therefore our idea 
> was to add
> > some
> >> informations like function definitions in the C-index. We created a
> > Java
> >> class PL8Language implementing the ILanguage interface from the
> > ILanguage
> >> Extension Point of the CDT. The parser of the PL8 should 
> not create 
> >> an
> > own
> >> index, but should add the functions of PL8 language to the index,
> > created by
> >> the CDT-Parser.
> >> If I click e.g. on a PL8-function in a C-file, the 
> C-indexer searches
> > for
> >> the function in the now combined index for the location of the
> > function and
> >> jumps to it. If I click in a PL8-file, my own indexer 
> searchs for the 
> >> function in the combined index.
> >>
> >> I think the solution is to implement the 
> getASTTranslationUnit and my
> > own
> >> ModelBuilder.
> >> I tried to implement the getASTTranslationUnit in this way.
> >>
> >> public IASTTranslationUnit getASTTranslationUnit(CodeReader reader,
> >>                         IScannerInfo scanInfo, ICodeReaderFactory 
> >> fileCreator,
> >>                         IIndex index, IParserLogService 
> log) throws 
> >> CoreException {
> >>
> > System.out.println("PL8Language::getASTTranslationUnit");
> >>                 final ISourceCodeParser parser= new 
> >> PL8SourceCodeParser(index);
> >>                 // Parse
> >>                 IASTTranslationUnit ast= parser.parse();
> >>                 return ast;
> >>
> >>         }
> >>
> >> The parse function of my SourceCodeParser looks like the following:
> >>
> >> public IASTTranslationUnit parse() {
> >>                 System.out.println("PL8SourceCodeParser::parse");
> >>                 IASTTranslationUnit result;
> >>                 //Create a new TranslationUnit
> >>                 translationUnit = new CASTTranslationUnit();
> >>                 translationUnit.setOffset(0);
> >>                 translationUnit.setIndex(index);
> >>
> >>                 //Name of the function
> >>                 char name_str[] = {'A', 'B'};
> >>                 CASTName declaratorName = new CASTName(name_str);
> >>
> >>                 //new SimpleDeclaration
> >>                 IASTSimpleDeclaration declaration = new 
> >> CASTSimpleDeclaration();
> >>
> >>                 IASTStandardFunctionDeclarator declarator = new 
> >> CASTFunctionDeclarator(declaratorName);
> >>                 declaration.addDeclarator(declarator);
> >>
> >>                 CASTSimpleDeclSpecifier declSpec = new 
> >> CASTSimpleDeclSpecifier();
> >>                 declaration.setDeclSpecifier(declSpec);
> >>
> >>                 translationUnit.addDeclaration(declaration);
> >>
> >>                 result = translationUnit;
> >>                 translationUnit = null;
> >>
> >>                 return result;
> >>         }
> >>
> >> The goal is to add a function AB to the index. But the current
> > situation is
> >> different. There is no function with the name AB in the 
> index and at
> > the
> >> moment I had no idea what the reason is. The return value of the 
> >> parse function is the right one. The return value has the 
> function included.
> >> At the moment I found no other way to write into the 
> index, which is
> > used
> >> for the source code navigation.
> >>
> >> I also searched for a solution in the CDT Wiki in the 
> topic Design. 
> >> It
> > is
> >> clearly explained about the CDT works, but no explanation 
> how I can 
> >> implement my idea.
> >>
> >> So my question to you, where is my mistake or is it generally 
> >> possible
> > to
> >> implement my idea?
> >> Is there anything additional I have to do or can you point me to an
> > example
> >> ?
> >>
> >> Thank you in advance!
> >>
> >> Kind regards
> >>
> >> Michael
> >> _______________________________________________
> >> 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
> 


Back to the top