Developer forums (C::B DEVELOPMENT STRICTLY!) > Compiler Framework Redesign
Compiler framework redesign (?)
thomas:
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...
tiwag:
one compiler per project is pretty sufficient, one always can group several projects in a workspace - this is what i do for several used compiler sets. and with inter-project-dendencies properly set you can automate the build process over projects perfectly.
tiwag:
--- Quote from: thomas on January 02, 2006, 05:44:12 pm ---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...
--- End quote ---
well thats obviously true !
but think of the Project's Build-options-dialog, where you can change the "selected compiler"
when one wants to change the compiler setting here, it could be possible to automate
to transfer the needed settings for the new selected compiler - at least for the basic
common options as declared above.
as it is now, all present settings are only preserved - this makes the least sense.
rickg22:
--- Quote from: thomas on January 02, 2006, 05:44:12 pm ---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...
--- End quote ---
No, but my intention was to be able to save one same project with switches for different compilers.
i.e. storing the MSVC and GCC configs in one same cbp.
Yiannis, please explain to me because it seems i kinda missed the boat with the latest "target" changes on the build process.
For a project like Code::Blocks, which has a lot of targets, how could this (having switches for diff compilers on one same cbp) be done?
Edit: Thanks, tiwag. But look at the current "project build options" dialog. 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? Currently, whenever we switch the compiler for a project or target, the target's build options are updated. Wouldn't it be good to store the options for all the compilers used? i.e. a target having a set of options for GCC and for MSVC, and when compiling, only the options for the respective compiler were used... this (unlike being forced to use different projects/workspaces) seems very intuitive to me.
Yiannis, your stance on this?
Edit again: Thanks again, tiwag, we seem to think very alike! :lol:
Michael:
--- Quote from: mandrav on January 02, 2006, 09:17:56 am ---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.
--- End quote ---
I must admit, I have misunderstood it :). I thought the idea was to redesign the compiler infrastructure from scratch.
--- Quote from: mandrav on January 02, 2006, 09:17:56 am ---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.
--- End quote ---
The use of XML is a very good idea. IMHO, it would also be important the definition of an XML schema file which defines the syntax of the XML file.
--- Quote from: mandrav on January 02, 2006, 09:17:56 am ---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.
--- End quote ---
The use of a script language within the XML file it is also interesting and IMHO a good way to go. It makes me remember of MPEG-21 DIP (even if they use javascript) :).
--- Quote from: mandrav on January 02, 2006, 09:17:56 am ---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.
--- End quote ---
Yes, now all is more clear. Thank you for your explanations.
Michael
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version