Author Topic: Compiler framework redesign (?)  (Read 46825 times)

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Compiler framework redesign (?)
« 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.
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.
Be patient!
This bug will be fixed soon...

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Compiler framework redesign (?)
« Reply #1 on: January 02, 2006, 09:51:10 am »
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:

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: Compiler framework redesign (?)
« Reply #2 on: January 02, 2006, 09:56:37 am »
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) ;)
Be patient!
This bug will be fixed soon...

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Compiler framework redesign (?)
« Reply #3 on: January 02, 2006, 10:20:29 am »
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?

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: Compiler framework redesign (?)
« Reply #4 on: January 02, 2006, 10:40:08 am »
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 ? ;)))).
Be patient!
This bug will be fixed soon...

Offline takeshi miya

  • Lives here!
  • ****
  • Posts: 1487
Re: Compiler framework redesign (?)
« Reply #5 on: January 02, 2006, 10:49:22 am »
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 :D

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Compiler framework redesign (?)
« Reply #6 on: January 02, 2006, 11:18:29 am »
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.

Quote
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Compiler framework redesign (?)
« Reply #7 on: January 02, 2006, 11:56:43 am »
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.


Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Compiler framework redesign (?)
« Reply #8 on: January 02, 2006, 02:31:23 pm »
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)
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Compiler framework redesign (?)
« Reply #9 on: January 02, 2006, 05:09:33 pm »
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?

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Compiler framework redesign (?)
« Reply #10 on: January 02, 2006, 05:24:09 pm »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Compiler framework redesign (?)
« Reply #11 on: January 02, 2006, 05:28:50 pm »
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.

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Compiler framework redesign (?)
« Reply #12 on: January 02, 2006, 05:31:55 pm »
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.

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 4986
Re: Compiler framework redesign (?)
« Reply #13 on: January 02, 2006, 05:33:12 pm »
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

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Compiler framework redesign (?)
« Reply #14 on: January 02, 2006, 05:42:02 pm »
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.
« Last Edit: January 02, 2006, 05:43:56 pm by rickg22 »

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Compiler framework redesign (?)
« Reply #15 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...
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Compiler framework redesign (?)
« Reply #16 on: January 02, 2006, 05:46:42 pm »
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.

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Compiler framework redesign (?)
« Reply #17 on: January 02, 2006, 05:53:37 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...

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.

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Compiler framework redesign (?)
« Reply #18 on: January 02, 2006, 05:54:49 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...

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:

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: Compiler framework redesign (?)
« Reply #19 on: January 02, 2006, 05:56:16 pm »
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.

I must admit, I have misunderstood it :). I thought the idea was to redesign the compiler infrastructure from scratch.

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.

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.

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.

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

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.

Yes, now all is more clear. Thank you for your explanations.

Michael

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Compiler framework redesign (?)
« Reply #20 on: January 02, 2006, 05:57:02 pm »
... 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

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: Compiler framework redesign (?)
« Reply #21 on: January 02, 2006, 06:10:38 pm »
So you want some more details, huh? ;)
Here's some food for thought:

  • One XML file per compiler.
  • Contains the toolchain (programs) that make up this compiler and connects the separate tools together (we could probably use some scripting here to avoid hard-coding logic in C::B).
  • Contains some high-level mandatory options. Something like "debug", "optimize", "target cpu", etc. These high-level options will be defined by C::B and all compilers must implement them (even if they 're just dummy :P). This should take care of the "switching-compilers-back-and-forth" issue ;)

Another, short-term goal (i.e. before next release), is to 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.
Be patient!
This bug will be fixed soon...

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Compiler framework redesign (?)
« Reply #22 on: January 02, 2006, 06:17:45 pm »
Cool!!! :)

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Compiler framework redesign (?)
« Reply #23 on: January 02, 2006, 06:22:30 pm »
... 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 !

Offline yop

  • Regular
  • ***
  • Posts: 387
Re: Compiler framework redesign (?)
« Reply #24 on: January 07, 2006, 09:23:08 pm »
I just remembered what else I was thinking for the compiler plugin and luckily I had my browser open (I'd forget it otherwise...). The precompiled headers support should be available for all compilers that support it (and probably have an option that will disable the whole process if not). This should also be customizable per compiler (I know that linux icc has about the same syntax as gcc when it comes to precompiled headers), like the rest of the commands to the compiler are.
Life would be so much easier if we could just look at the source code.

PChris

  • Guest
Re: Compiler framework redesign (?)
« Reply #25 on: May 07, 2006, 09:46:25 am »
I just want to add my thoughts to the new Compiler Framework.
I think we could go with a structure like this:
In a separate directory we could put the XML files for the toolset (MinGW, Intel, Microsoft, ...):
Code: XML
  1. <toolset>
  2.   <code>MinGW</code>
  3.   <compiler>
  4.     <code>gcc</code>
  5.     <version>4.1.0</version>
  6.     ...
  7.   </compiler>
  8.   <rescomp>
  9.     <code>windres</code>
  10.     <version>...</version>
  11.   </rescomp>
  12.   ... other tools in the toolset ...
  13. </toolset>

And in a subdirectory named after the toolset (minGW) we could put XML descriptors for each tool. For the version control there are two things I thought of: Declare a base version, and add tags for the upcoming versions with nodes like <addfeature> or <removefeature>, or to create separate files for each major compiler version (gcc410.xml, gcc403.xml...)
Code: XML
  1. minGW/gcc.xml
  2.  
  3. <compiler>
  4.   <code>gcc</code>
  5.   <base>
  6.     <version>4.0.3</version>
  7.     <optiongroup>
  8.       <groupname>Optimization</groupname>
  9.       <option id="1">
  10.         <name>Optimize fully</name>
  11.         <value>-O3</value>
  12.       </option>
  13.       ...
  14.     </optiongroup>
  15.   </base>
  16.   <versionchanges>
  17.     <versionchange id="4.1.0">
  18.       <addoption id="54">
  19.         <name>Some new feature</name>
  20.         <value>-XxX</value>
  21.       </addoption>
  22.       <removeoption>
  23.         <id>1</id>
  24.       </removeoption>
  25.     </versionchange>
  26.     ...
  27.   </versionchanges>
  28. </compiler>
  29.  

OR

Code: XML
  1. minGW/gcc410.xml
  2.  
  3. <compiler>
  4.   <code>gcc</code>
  5.   <version>4.1.0</version>
  6.   <optiongroup>
  7.     <groupname>Optimization</groupname>
  8.     <option id="1">
  9.       <name>Optimize fully</name>
  10.       <value>-O3</value>
  11.     </option>
  12.     ...
  13.   </optiongroup>
  14.   ...
  15. </compiler>
  16.  

Is this a way to go? Please tell me, so I can think further  :D

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Compiler framework redesign (?)
« Reply #26 on: May 07, 2006, 02:45:15 pm »
We use something like depicted in your first code sample, except that we use named stages rather than dedicated tags for compiler and rescomp. There are separate configuration files for different versions of the same compiler.

We implement options slightly different too, insofar as we have behaviours and properties. The former are general, the latter compiler-specific.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

PChris

  • Guest
Re: Compiler framework redesign (?)
« Reply #27 on: May 07, 2006, 03:52:51 pm »
That's great news!  :D
How exactly is the version separation solved? I'd like to know more about the upcoming solution ;)

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Compiler framework redesign (?)
« Reply #28 on: May 07, 2006, 03:59:17 pm »
That's done using a challenge-response system.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Yury Benesh (aka ybx)

  • Multiple posting newcomer
  • *
  • Posts: 16
    • http://ybx.narod.ru
Re: Compiler framework redesign (?)
« Reply #29 on: August 15, 2006, 10:33:27 am »
Clean command should also get additional temporary/itermediary files info, e.g. the OpenWatcom compiler produces *.err files if there are errors and/or warnings during the compilation.

Offline nzoltan

  • Multiple posting newcomer
  • *
  • Posts: 39
Re: Compiler framework redesign (?)
« Reply #30 on: August 20, 2006, 12:26:02 pm »
Hi,

If you really want redesign the compiler framework, I recommend that see CBuilderX IDE.

announce (1.5 for windows free edition):
http://bdn.borland.com/article/0,1410,32751,00.html

download (after 7 q&a): 133MB
http://info.borland.com/survey/cbx15_mobile_edition.html

Also you will need a Borland Developer Network registration (free). It is an excellent cross platform IDE - and "just" an IDE - (similar for C::B) support many of compiler sets (every compiler described an extension XML file, and the user can create new easy), but unfortunately CBX has many many many bugs and totally unsupported by Borland (dead project).

Major features:

- Build options dialog not just for project but for every file
- 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)
- Revert menu for editor tabs

...and many more features.

Good luck,
a new C::B user.

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Compiler framework redesign (?)
« Reply #31 on: August 20, 2006, 04:50:10 pm »
I think a preview of the final command line would be a useful feature.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9415
Re: Compiler framework redesign (?)
« Reply #32 on: August 20, 2006, 08:03:17 pm »
- Build options dialog not just for project but for every file
- 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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 4986
Re: Compiler framework redesign (?)
« Reply #33 on: August 20, 2006, 08:22:50 pm »
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.

Offline nzoltan

  • Multiple posting newcomer
  • *
  • Posts: 39
Re: Compiler framework redesign (?)
« Reply #34 on: August 20, 2006, 08:45:26 pm »
All this is achievable with C::B, too. See my sig and have a look at C::B file properties, too.
With regards, Morten.

- Build options dialog not just for project but for every file

In C::B, the file build options dialog and project options dialog is very different, CBX provide same dialog.


- Multiple build tools (and options) for same project (example: msvc on windows, gcc on linux)

I can`t do this with C::B:
1. I select the project, 2. right click 3. select properties menu
then I cannot change compiler because the drop-down list is grayed.


- Project tree also contain the final binary file entry (exe, dll, so, a, lib etc.) and have a build options dialog


In CBX this dialog show the linker options.


----
Sorry my english is very poor, and at this time, I am only present perfect (with bugs). :(
« Last Edit: August 20, 2006, 10:56:34 pm by nzoltan »

Offline nzoltan

  • Multiple posting newcomer
  • *
  • Posts: 39
Re: Compiler framework redesign (?)
« Reply #35 on: August 20, 2006, 08:47:49 pm »
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.

Exactly! But I think, a read only preview is abundant.

Offline chikigai

  • Multiple posting newcomer
  • *
  • Posts: 33
Re: Compiler framework redesign (?)
« Reply #36 on: September 20, 2006, 08:48:28 am »
Hello,

Hope I'm not going to off topic here, but since it may relate to the Compiler framework redesign, I'm putting the details here.
I was thinking of using the ARM9 compiler through Code::Blocks (without custom makefiles) but ran into a few difficulties.
The main difficulty is that the ARM9 compiler suite has the following utilities:

1. ASM Compiler
2. C Compiler
3. C++ Compiler
4. Librarian
5. Dynamic Linker
6. Static Linker

Basically, the number of utilities is far larger than the basic set most compiler suites have.
When a project contains a combination of C and Assembly files, the difficulty increases since the define switch is different between the ASM and C compiler ('-D' for the C compiler and '--PD' for the ASM compiler).
I thought about extending the Compiler Framework but it is next to impossible without breaking what's already in place.

I was wondering if the planned XML based Compiler Framework would allow integration of compiler suites of this nature.

Yes, I understand that the integration of this sort of compiler suite probably does not match what Code::Blocks is intended/planned to support, but again, I was just wondering!
[Development Environment]
OS: WinXP SP3
IDE: Code::Blocks Nightly Build SVN Rev.6080 wxWidgets: 2.8.10 Windows Unicode Build SVN: 1.6.x

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: Compiler framework redesign (?)
« Reply #37 on: September 20, 2006, 09:03:46 am »
Quote
I was wondering if the planned XML based Compiler Framework would allow integration of compiler suites of this nature.

Short answer: yes.
Be patient!
This bug will be fixed soon...

Offline chikigai

  • Multiple posting newcomer
  • *
  • Posts: 33
Re: Compiler framework redesign (?)
« Reply #38 on: September 22, 2006, 02:19:02 am »
Thanks for the quick reply!
Will wait patiently for the new framework!  :P
[Development Environment]
OS: WinXP SP3
IDE: Code::Blocks Nightly Build SVN Rev.6080 wxWidgets: 2.8.10 Windows Unicode Build SVN: 1.6.x

Offline kingfox

  • Multiple posting newcomer
  • *
  • Posts: 38
Re: Compiler framework redesign (?)
« Reply #39 on: November 15, 2007, 03:57:04 pm »
How about the progress of redesigning the compiler framework ?

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: Compiler framework redesign (?)
« Reply #40 on: November 15, 2007, 04:07:36 pm »
How about the progress of redesigning the compiler framework ?

No progress. This is planned for v2.0.
Be patient!
This bug will be fixed soon...

Offline lescho

  • Single posting newcomer
  • *
  • Posts: 2
Re: Compiler framework redesign (?)
« Reply #41 on: August 16, 2010, 01:27:24 pm »
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?

Another thing is that I've to change the actions of the 'Run' command. As I can't simply execute a AVR32 elf on my PC, I like to execute the external avr32program tool to program the image into the corresponding target MCU. I didn't found anything about that in the compiler plugins. Can someone point me to the right direction.

Thanks Lescho

Offline dasfoo

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: Compiler framework redesign (?)
« Reply #42 on: November 02, 2010, 09:40:54 am »
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

I'm poking around at this. With an eye to adding the Yagarto compiler this way. Currently working on the code to save and load compiler definitions from an xml file(s).  Currently I'm looking at how ConfigManager handles the default.conf file so as to keep things consistent and not reinvent the wheel.


Offline dasfoo

  • Multiple posting newcomer
  • *
  • Posts: 13
Re: Compiler framework redesign (?)
« Reply #43 on: November 02, 2010, 11:20:43 pm »
An issue to address, especially with the AVR compilers is that it's possible for there to be more than one compiler installed.

For instance I have, WinAVR-20071221 and WinAVR-20090313 installed.  For a few older projects I need the 2007 version because it produces slightly smaller code.  But for new projects I'm using 20090313.

Seems that it would be a good idea if the AutoDetectCompiler routine would do a little more than detect the first compiler in the path, it should grind through the path and look for all instances and report any it finds.

Another nice thing would be if the Auto Detect routine would ask the compiler to report it's version information.  AKA arv-gcc -v returns gcc version 4.3.2 (WinAvr 20090313)