Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Design of Compiler-Plugin

(1/1)

kobi:
Has anyone did a compiler plugin for a non-C/CPP compiler?
I had a look at the SDK and the CB source and the compiler base class delivers a structure called CompilerPrograms which is declared as

struct CompilerPrograms
{
    wxString C; // C compiler
    wxString CPP; // C++ compiler
    wxString LD; // dynamic libs linker
    wxString LIB; // static libs linker
    wxString WINDRES; // resource compiler
    wxString MAKE; // make
    wxString DBG; // debugger
};

Do I have to derive from CompileOptionsBase if I want to support a non-C/CPP compiler ?
Nevertheless CB is an incredible piece of work :mrgreen:

rickg22:
You're right, we should extend CB to support other languages. Please drop a feature request at sourceforge about it. Thx!

mandrav:
I have laid down a design which allows for a language-agnostic compiler plugin, but I doubt we 'd make such a change before 1.0.
One of the initial goals, however, was (and still is) complete and unlimited functionality ;)

Yiannis.

kobi:
As I understand the current design models the compiler as a set of programs that act on specific source files.

A better granularity could be achieved if you look at these programs on their own: They are processors
which transform an input file into an output file. There are different types of processors
(e.g. RC compilers, CPP compilers, ScannerGenerators, ParserGenerators ...)

A set of processor instances could be seen as a compiler suite.
Every compiler installation comes with their own set of preferred processors. But possibly one or more of the processors are missing (Most compiler installations do not have Lex/Yacc or a documentation tool like DoxyGen). In this case you need a kind of fallback mechanism which selects the tool from a global pool.

Within a project you normally have a two step transformation (compiling, linking). One could think about further steps (e.g. deployment, documentation) but I think that such steps are better hosted within dedicated projects.

BTW: the developers of the SharpDevelop project have made their design document "Dissecting a C# Application: Inside SharpDevelop" available for free. See http://www.icsharpcode.net/OpenSource/SD/InsideSharpDevelop.aspx
I think its a valuable source for ideas related to building an IDE.

mandrav:

--- Quote ---A better granularity could be achieved if you look at these programs on their own: They are processors
which transform an input file into an output file. There are different types of processors
(e.g. RC compilers, CPP compilers, ScannerGenerators, ParserGenerators ...)

--- End quote ---

This is almost what I 've come up with: operate with "programs" in an abstract level :)
I 'll give more info once the design has been stabilized.
Thanks for sharing your thoughts.

Yiannis.

Navigation

[0] Message Index