Compiler framework redesign (?)

[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.

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 ? ))).

[takeshimiya]

XML will be great for the Compiler plugin, but what for example the CodeCompletion, where suppose I want to write different parsers to each language, while sharing some common things. How that can be done with the Plugins architecture?

I'm asking because I would like to know myself how to do that on the C++ side.
Plugins (C++, Java, PHP) for a plugin (CodeCompletion) is the right way?
Or only one big plugin (CodeCompletion) where each language parser would be derived from the CodeCompletion commonality?

I know really nothing about plugin frameworks in C++, so that's why I want to know

[thomas]

XML will be great for the Compiler plugin, but what for example the CodeCompletion, where suppose I want to write different parsers to each language, while sharing some common things.

You're very welcome to contribute to a universally pluggable code completion plugin. Talk to Rick though, he is working on the present implementation, so you don't step on each other's feet.

I know really nothing about plugin frameworks in C++

A plugin is a DLL which exports at least one known symbol, for example GetPluginFunction(). That is the whole magic.
The Code::Blocks plugins export a little more than one symbol, but that's not important. You don't need to know, since you will just derive from cbPlugin which does that stuff automatically.

[tiwag]

which thread should be used for discussions regarding the user-interface ?

i'm thinking of showing inherited settings ( maybe as greyed options ) from global-compiler or project-settings when editing the targets-settings.

[280Z28]

Several of the "most important" things I mentioned will probably be solved by these new descriptor files anyway. (my #2, 3, 4, and 6 from the other thread)

[rickg22]

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.

Alright! That's a good idea. Just a question - what happens if we want to implement in a target/project different flags for different compilers?

i.e. having "global options" (apply to all compilers) and "compiler-specific options" (apply for only one compiler, i.e. MSVC) for each project/target. Is this possible with the current compileroptionsbase, compiletargetbase, etc?

[thomas]

Would that make sense? Different compilers are not options-compatible (except by pure coincidence).

The only really useful thing I could think of is "number of concurrent threads", and even here I am not sure if it wouldn't better be left compiler-specific.

[tiwag]

i think this would make perfect sense for a small set of basic options.
the most basic options are
debug / non debug build,
static lib,
shared lib,
console project,
gui project.
(and a few more if we investigate a little ...)

if there could be a set of compiler settings which are translateable through different compilers this would be a great feature, to automatically transfer projects from VC to gcc for example.

[rickg22]

Would that make sense? Different compilers are not options-compatible (except by pure coincidence).

So that means a project should specify which compiler it has its options set, right? Right now I'm thinking of the problem of multiple-compiler development, i.e. for GCC and MSVC. Currently we need a different project per compiler. Just switching the compiler leaves us with incompatible switches, and was one of my reasons for starting the redesigning forum.

[killerbot]

Would that make sense? Different compilers are not options-compatible (except by pure coincidence).

So that means a project should specify which compiler it has its options set, right? Right now I'm thinking of the problem of multiple-compiler development, i.e. for GCC and MSVC. Currently we need a different project per compiler. Just switching the compiler leaves us with incompatible switches, and was one of my reasons for starting the redesigning forum.

different target

[rickg22]

different target

Yes, but look at what Yiannis said about multi configurations here.

I 've though about "configurations" too (and almost started implementing them). I 'm not sure though it's a good idea, at this stage, to make such intrusive changes. Maybe after 1.0?

Yiannis.

(And I'm really not sure if doing it with targets is the right solution... seems too confusing for me right now)

Keep in mind that this redesign is long-term, for post-1.0 changes (i started the topic in advance, so we can discuss about it (in parallel) while we keep working with our standard schedule, later we can work on the ideas discussed here.