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]

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.

[rickg22]

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:

[Michael]

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

[tiwag]

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

[mandrav]

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

[rickg22]

Cool!!!

[tiwag]

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

[yop]

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.

[PChris]

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

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

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

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>

OR

Code: xml

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>

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

[thomas]

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.

[PChris]

That's great news! 
How exactly is the version separation solved? I'd like to know more about the upcoming solution

[thomas]

That's done using a challenge-response system.

[Yury Benesh (aka ybx)]

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.