Author Topic: Design of Compiler-Plugin  (Read 7240 times)

kobi

  • Guest
Design of Compiler-Plugin
« on: May 12, 2005, 05:33:37 pm »
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:

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Design of Compiler-Plugin
« Reply #1 on: May 12, 2005, 05:47:40 pm »
You're right, we should extend CB to support other languages. Please drop a feature request at sourceforge about it. Thx!

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Design of Compiler-Plugin
« Reply #2 on: May 12, 2005, 09:09:35 pm »
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.
Be patient!
This bug will be fixed soon...

kobi

  • Guest
Design of Compiler-Plugin
« Reply #3 on: May 13, 2005, 09:21:40 am »
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.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Design of Compiler-Plugin
« Reply #4 on: May 13, 2005, 09:48:57 am »
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 ...)

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.
Be patient!
This bug will be fixed soon...