[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] adding a new language to the CDT
|
There is a lot of history here. There has long been a need at Eclipse to
put common IDE bits into sharable layers. LTK was JDT's attempt to
factor out common bits but really only contains the AST rewriting and
refactoring UI bits. And from what I saw of the JDT, that's all that was
in there that could be reused that isn't already in the Eclipse
Platform. The CDT never got around to factoring out our common bits, but
it would be a great exercise if we could find someone to invest in that.
The statement that "JDT and CDT are purposely specific to their
languages" is true only for JDT. The CDT supports at a minimum two
languages, C and C++. We treat them as the two separate languages that
they are. We did some work to support the Photran project to allow them
to plug in Fortran in the same way. My (now fading) hope was that the
Ada project could do the same. And, believe it or not, C# is still
floating around, and we've seen repeated requests for Objective-C/C++.
There are a lot of reusable parts to the CDT - including the build and
debug systems (which we have shown to work with new languages
unchanged). We have made attempts to factor out the editor and
parsing/indexing frameworks into common parts that can be extended. This
is what ILanguage and ILanguageUI are intended to support. But it's
certainly not complete or fully exercised.
Writing an IDE from scratch is a huge job. Getting ideas from JDT and
CDT can help but not significantly enough make a big difference. There
was a Technology project started at Eclipse that could generate IDEs for
you, but I haven't heard much from them lately (to the point where I
can't remember the name of it). So reusing the CDT is probably the best
choice. But even with that, there's still a huge job ahead.
Doug.
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Hilliard, Bill
> Sent: Tuesday, October 28, 2008 1:16 PM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] adding a new language to the CDT
>
> 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
>
