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.
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.
Would that make sense? Different compilers are not options-compatible (except by pure coincidence).
different targetWould 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
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.
Well, the problem is that different compilers do not use the same switches. They do not even use the same filenames or compatible library images...
There is no way you can convert a MSVC project to gcc with one click...
Well, the problem is that different compilers do not use the same switches. They do not even use the same filenames or compatible library images...
There is no way you can convert a MSVC project to gcc with one click...
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.
... Wouldn't it be good that if you switched the compiler (i.e. from MSVC to GCC), a new set of default options would appear, and if you switched back, the first options were just like you left them before changing the compiler dropdown?totally agree
... add cross-platform support in the project file. This way you could define different sets of options based on the platform. This is a relatively easy change. The way I 've thought about it, is to add an extra attribute to <Project>, <Target>, <Compiler> and <Linker> tags defining the target platform. If not there, defaults to "any" (much like it works now, platform-agnostic and backwards-compatible). So, one would create a windows-target and a linux-target and the correct one would be chosen automatically by C::B based on the platform it runs in.great ! very important i think !
<toolset>
<code>MinGW</code>
<compiler>
<code>gcc</code>
<version>4.1.0</version>
...
</compiler>
<rescomp>
<code>windres</code>
<version>...</version>
</rescomp>
... other tools in the toolset ...
</toolset>
minGW/gcc.xml
<compiler>
<code>gcc</code>
<base>
<version>4.0.3</version>
<optiongroup>
<groupname>Optimization</groupname>
<option id="1">
<name>Optimize fully</name>
<value>-O3</value>
</option>
...
</optiongroup>
</base>
<versionchanges>
<versionchange id="4.1.0">
<addoption id="54">
<name>Some new feature</name>
<value>-XxX</value>
</addoption>
<removeoption>
<id>1</id>
</removeoption>
</versionchange>
...
</versionchanges>
</compiler>
minGW/gcc410.xml
<compiler>
<code>gcc</code>
<version>4.1.0</version>
<optiongroup>
<groupname>Optimization</groupname>
<option id="1">
<name>Optimize fully</name>
<value>-O3</value>
</option>
...
</optiongroup>
...
</compiler>
- Build options dialog not just for project but for every fileAll this is achievable with C::B, too. See my sig and have a look at C::B file properties, too.
- Multiple build tools (and options) for same project (example: msvc on windows, gcc on linux)
- Project file can be "excluded" (ignored when build, but show is the project)
- Project tree also contain the final binary file entry (exe, dll, so, a, lib etc.) and have a build options dialog
- Build options dialog show a final preview of compiler command line (build tool and every local and inherited options)
All this is achievable with C::B, too. See my sig and have a look at C::B file properties, too.
With regards, Morten.
I think he is talking about a preview of how the command line looks with just all the settings appended (so no macros replacement yet) and whitout issuing a build. Several IDE's show it like that (some read only) others even editable.
I was wondering if the planned XML based Compiler Framework would allow integration of compiler suites of this nature.
How about the progress of redesigning the compiler framework ?
Hello,
during the weekend I tried to add the GCC AVR32 compiler to CB. A just copied the ARM sources and added the new stuff to the compiler factory. It works but I'm not quite happy with the process of adding a compiler. A solution like the one described at the beginning of this thread would be much more convenient. Does someone has this on the agenda?
Thanks Lescho