XML based compilers

[Alpha]

Another (simpler) option is to have the compiler class hold the autodetector and provide a single method
[...]

OK, I will experiment with this.  Would you happen to know if this technique is used elsewhere in Code::Blocks, so that I could examine it?

I believe I will be busy for a few days, so I am not certain when my next patch will come.

[MortenMacFly]

Would you happen to know if this technique is used elsewhere in Code::Blocks, so that I could examine it?

Mmmmh... not to my knowledge. It would be a tooling class. So it its easier for you to derive from - just go that way. In the end from an interface point of view its the same.

I believe I will be busy for a few days, so I am not certain when my next patch will come.

No üroblem, leaves more time for me to test. BTW: already now I have used it a lot w/o issues. Just the patch needs tweaks to compile w/o PCH and on wx 2.9.x.

[Alpha]

I believe I will be busy for a few days, so I am not certain when my next patch will come.

... maybe that was a bit more than a few days...

I think I have a working extension to the <if> statements now.  Does anyone have specific example flags that should be hidden if the compiler is detected as a certain version?  (Or a link to where I can find a listing of flags added by compiler version.)

[Alpha]

- compileroptionsdlg: The global var "menuOption" should become a class member var "m_MenuOption"

By the way, this change causes the passing on of the event id to mysteriously fail (no errors are raised, and according to gdb, m_MenuOption reverts -1 when OnFlagsPopupClick() returns).

However, it does work if I make it a static class member.  Would this still be the preferred method?

[MortenMacFly]

Does anyone have specific example flags that should be hidden if the compiler is detected as a certain version?

Certainly the platform flags usually need attention. Also, -std=c++0x and -std=c++11 and some warnings (like -Weffc++) have not always been available.

The GCC webpage will always tell you what's new, like here:
http://gcc.gnu.org/gcc-4.3/changes.html
...under the section "IA-32/x86-64" you'll see that i.e. -mtune=core2 has been added in this version (4.3).

From my point of view we should consider the last 3.x.x version in contrast to 4.0.x and then 4.5, 4.6 and 4.7 which should cover the main up-to-date compilers. Maybe not all of the flags, but the ones that seem important. If its configurable in the end we can do it step by step anyways...

[MortenMacFly]

By the way, this change causes the passing on of the event id to mysteriously fail (no errors are raised, and according to gdb, m_MenuOption reverts -1 when OnFlagsPopupClick() returns).

Huh? How weird is that?! Maybe we are overriding a member variable with the same name of a base class?! I'll have a look.

However, it does work if I make it a static class member.  Would this still be the preferred method?

...in the mean time: Yes. :-)

[Alpha]

OK, thanks.

Now that options are almost all loaded with the same code, is it fine to make Compiler::Reset() and Compiler::LoadDefaultRegExArray() non-pure virtuals?

[MortenMacFly]

Now that options are almost all loaded with the same code, is it fine to make Compiler::Reset() and Compiler::LoadDefaultRegExArray() non-pure virtuals?

Depends on what you mean with almost here...?! If its not the same, shouldn't it remain virtual because in that case a compiler needs to implement it?!

[MortenMacFly]

I've created a branch for you work here:
http://svn.berlios.de/svnroot/repos/codeblocks/branches/xml_compiler
If you have time, please switch to it and provide patches against the branch. This should make things easier and track-able. Notice that I also integrated a few corrections from my side concerning compiler errors and alike (no functional changes). So be careful, I guess the first time you need some clever merging. If you can't do that, just provide patches against the branch, I'll do the rest.

[Alpha]

Now that options are almost all loaded with the same code, is it fine to make Compiler::Reset() and Compiler::LoadDefaultRegExArray() non-pure virtuals?

Depends on what you mean with almost here...?! If its not the same, shouldn't it remain virtual because in that case a compiler needs to implement it?!

They would still remain virtual

Code

virtual void Reset();

just not pure vitrual

Code

virtual void Reset() = 0;

By almost, I mean all of the LoadDefaultRegExArray() look like

Code

void CompilerMSVC8::LoadDefaultRegExArray()
{
    m_RegExes.Clear();
    LoadRegExArray(GetID());
}

and most of the Reset() look like

Code

void CompilerMSVC8::Reset()
{
    m_Options.ClearOptions();
    LoadDefaultOptions(GetID());

    LoadDefaultRegExArray();

    m_CompilerOptions.Clear();
    m_LinkerOptions.Clear();
    m_LinkLibs.Clear();
    m_CmdsBefore.Clear();
    m_CmdsAfter.Clear();
}

The Reset()s that are different include LCC (init member var), DMD (add some link libs), and the main GCC (call SetVersionString()).
In my opinion, it make sense to move this default implementation into the base, so newly written compilers will automatically try to load their XML files.  If a compiler does not want to load from XML (or wants to do additional items), then these methods can still be re-implemented, overriding the default.

I've created a branch for you work here:

Thank you (the patches against the trunk were becoming almost unreadable due to size).  I have finished merging, and will be doing a few tests; the next patch should come soon.

[Alpha]

Patch available (against XML branch).

Changed:

• New <if> statement directive (if the compiler is detected, some flags are now hidden based on version)
• Modified compiler id creation (will break .cbp's using arm, avr, msp430, ppc, or tricore)
• Some dialog tidying
• Files of the same weight are compiled alphabetically
• Improve MSVC2010 sdk auto-detection
• Moved EvalXMLCondition() back to Compiler
• Enumerated some ARM flags

[Alpha]

Documentation updated.

[MortenMacFly]

They would still remain virtual

Code

virtual void Reset();

just not pure vitrual

Code

virtual void Reset() = 0;

Ah - that makes sense, sure.

By almost, I mean all of the LoadDefaultRegExArray() look like
[...]
and most of the Reset() look like

Yes, is seems feasible that they are in base now. Maybe we can do it even easier: Reset calls ResetPrivate() which is the virtual method you need to override if you need to do something special and in its default implementation it does nothing (same for LoadXXX). This way, compilers were "forced" to use the default "Reset" (which is good I think) but still can do something special. To soften the requirements we could stick with the virtual Reset method. Although it would be not too bad to make Reset even non-virtual and protected in that case.

What do you think?

[MortenMacFly]

Patch available (against XML branch).

For the record: Applies flawlessly in the branch. Nice! (Not compiled in / tested though...)

Edit: I see the compilers individual code really shrinks... nice! :-)

[MortenMacFly]

One first feedback:
When running with debug log (and therefore warnings) enabled, now I get tons of warnings, that the command issued to detect the compiler could not be executed.

You should either disable logging for this step (http://docs.wxwidgets.org/2.8/wx_wxlognull.html), or check if the executable really exists before running the command. In the latter case make sure you account for possible macros.