Developer forums (C::B DEVELOPMENT STRICTLY!) > Compiler Framework Redesign

Compiler framework redesign (?)

(1/9) > >>

mandrav:
Let me state my thoughts about this infamous redesign.
It seems people misunderstand it.

The current compiler infrastructure has served us well, more than well I 'd say. As the project moved forward, some weaknesses have been identified and so a buzz started about redesigning it.
But does this mean to rewrite everything compiler-related from the ground up? No, I don't think so. The current plugin is in a quite good state and, by using a state-machine as of late, is quite extendable too.
What needs to change, is the sdk/compiler*.* files. This is the compiler framework I 'm referring to.
If we change the Compiler class to read/write XML configuration files, we will already have made the first step to easy customization and get rid of plugins/compilergcc/compiler*.* files (compilers implementations). This means that to add a new compiler in C::B, all one has to do is write one new XML file. We have to decide the format of this file, that is the crucial part.
We can (and should) use existing libraries to help us. For example, not many remember that we have a scripting language in C::B (AngelScript). We could use it for compiler options, for example. I mean, attach a script (as a tag in the XML file) to "Optimization" options to disable debugging when activated. Easy, simple, effective and already there.

I 'm not going into more details here, as my intention was to clear things up a bit.
I hope it's more clear now what I mean when I talk about "compiler framework redesign".

Yiannis.

takeshimiya:
Good to clear things up, and I agree with that vision of the "compiler framework redesign". :)

It would be good if you could also clear up what are your other goals for C::B.
I mean, in what direction the project will you want to put effort. Do you want to make C::B more like DevC++ (lightweight and with basic features), or would you like more the Eclipse approach (powerful and big, with lot's of plugins, and handling any language, not only C/C++).
And that is the most important, will it be all-centered on C/C++, or will support right from the start any language (I mean for example, if I want to support Java, will not have to write an entire new compiler plugin, instead I'll use the common things that have the compilers, and write only the differences).
If you want C::B become that way (equal support to any language), the KDevelop guys have come with a great solution, separating all the languages in 2 categories: compiled, and scripted languages.

Well, all of that resumes to:
Would you like C::B haves a KISS framework?
Would you like it to have a Powerful (as in Eclipse) framework?
Or something else perhaps, not yet decided?

What I'm referring is no more than a project Roadmap/Goals, so things are clear up from the start. :D

I only wonder towards where the best IDE out there will be geared :wink:

mandrav:
You shouldn't need to ask. If C::B was to follow the KISS approach, it wouldn't allow for plugins with such freedom (i.e. really become parts of the main app) ;)

takeshimiya:
Good to know :)

At the same time, I wonder, that if the plugins have such big freedom (ie. Compiler or Editor plugin) which are very powerfull, but not expandable per se. I mean, if I want to support a new language right now, probably my choice would be to clone the Compiler/CodeCompletion plugin, but any change made in one wouldn't see in the other.
Or if using inheritance, all languages would belong only to a very big Compiler plugin.

A plugin for a plugin makes sense? If not, I suppose that the commonality should belong to the SDK?

mandrav:
That's exactly what the redesign is for. To allow customization through XML files (one per-compiler (or language (don't you love these nested parentheses ? ;)))).

Navigation

[0] Message Index

[#] Next page