XML based compilers

[MortenMacFly]

Question: The only condition that <if></if> blocks currently recognize is platform - are there any other conditions that would be made use of during the loading of a compiler?

One thing I could think of is an if-statement to check for a compiler version... not sure how to handle this at startp w/o running the compiler though.

[Alpha]

Is it correct for me to assume that the GCC regexes (located in compilerMINGW.cpp) are applicable to all supported (C/C++) GCC variants (ARM, TriCore, ...)?

[MortenMacFly]

Is it correct for me to assume that the GCC regexes (located in compilerMINGW.cpp) are applicable to all supported (C/C++) GCC variants (ARM, TriCore, ...)?

I think it isn't wrong in a first place, but to be sure you'd have to ask the compiler guys developing these. I never worked with ARM/TriCore compilers.

However, from what I see they might override some of the options.

[MortenMacFly]

OK, here comes some more from the testing front:

First of all: Also the new patch works great, I didn't have to change a lot (just the very minor stuff I was already referring to).

• The flags dialog is well-hidden I'd say, so I suggest to add a (red) note below the compiler flags to inform the user that this is actually adaptable.
• The flags dialog should be resizable (I did this in my local copy already)
• I don't know if it is really needed to allow toggling the additional flags (for the checks) with this ">" button. Instead, I'd prefer to have them always visible below the major flags so see the full picture. The reason is that you look what's hidden there anyways... ;-)

What didn't work for me is when I add a flag with a different (new) category, the new category does not appear in the "Categories" choicebox of the compiler options, although its present.

The log-term goal should probably be to have the compiler setup (not the project's compiler options setup) unified in a single dialog, including the advanced stuff, reachable only from the compiler settings dialog. For now, you can change the compiler flags even in the project build options, which is kind of mis-leading I'd say. Also, I don't like having the different options scattered in so many dialogs with different access points. But in the end that's "fine-tuning" (maybe not on your list) and I believe we can even re-use the UI resources already created by then.

[MortenMacFly]

What didn't work for me is when I add a flag with a different (new) category, the new category does not appear in the "Categories" choicebox of the compiler options, although its present.

Oh well, now I figured out something else: Looking at the modified compiler XML file I realised that if you change a flag the <if> <else> sections are gone, meaning, that the options are no longer cross-platform. Also, the "Common" options are integrated and no longer linked. Is this by design?

[Alpha]

What didn't work for me is when I add a flag with a different (new) category, the new category does not appear in the "Categories" choicebox of the compiler options, although its present.

Oops; I forgot to refresh the categories when a new one is added.

Oh well, now I figured out something else: Looking at the modified compiler XML file I realised that if you change a flag the <if> <else> sections are gone, meaning, that the options are no longer cross-platform. Also, the "Common" options are integrated and no longer linked. Is this by design?

Design (mostly) and laziness (a little).  The modified XML is stored in the user profile, so it is very unlikely to shift platforms.  Also, resolution is not easy: if a flag is added between two flags that are inside the same <if> section, should the new flag be put into the <if>?  Should the <if> be split into two <if>s?
The common options must be unlinked because if a flag was modified/deleted that was loaded from a common location, there is no simple way to resolve; if the changed flag was saved back to the common location, it could unexpectedly alter multiple compilers.

The log-term goal should probably be to have the compiler setup (not the project's compiler options setup) unified in a single dialog, including the advanced stuff, reachable only from the compiler settings dialog.

I think this is the right direction, however I am not going to attempt it (yet).  I do not want to try to be too ambitious, and have to stop with only a half finished product to show for it.

Regexes and advanced compiler options (support for alternate build commands with file extension filters) are now integrated into the XML.  I will soon upload a patch with these and your suggested dialog modifications.

[MortenMacFly]

The modified XML is stored in the user profile, so it is very unlikely to shift platforms.

Ah - OK I didn't know that. If I got it right that means that the default files are distributed with C::B and installed in the "shared" folder of C::B and the modifications are in the user's profile directory and override the default C::B files, right? In that case it should be just fine because then you can easily revert to the default values or - if another user logs on - (s)he gets provided the initial default values, too.

Regexes and advanced compiler options (support for alternate build commands with file extension filters) are now integrated into the XML.  I will soon upload a patch with these and your suggested dialog modifications.

Great... I'll wait patiently...

[Alpha]

Regexes and advanced compiler options (support for alternate build commands with file extension filters) are now integrated into the XML.  I will soon upload a patch with these and your suggested dialog modifications.

Great... I'll wait patiently...

Here it is.  It also includes a recursion depth guard (in case some common file decides it is a good idea to recursively load itself, or another common file which references back to it) and the initial code in compilerXML.cpp (disabled because it is not yet functional).

If I got it right that means that the default files are distributed with C::B and installed in the "shared" folder of C::B and the modifications are in the user's profile directory and override the default C::B files, right?

Yes.  (At least, this is what it is supposed to do...)

By the way, does Code::Blocks programming style have a preference between wxT("text") and _T("text")?  (From what I can tell, they mean exactly the same thing.)

[Alpha]

Documentation updated.

[MortenMacFly]

Here it is.

Nice... will try ASAP...

By the way, does Code::Blocks programming style have a preference between wxT("text") and _T("text")?  (From what I can tell, they mean exactly the same thing.)

Not really, but I personally prefer the wxT macro. The wx guys recommend it, too and _T sometimes conflicts with equal definitions of other frameworks. wxT is safe instead and dedicated for wxWidgets. Remember, that for translation you'll need to use "_".

[MortenMacFly]

Some feedback already (just looking at the diff):

- compileroptionsdlg: The global var "menuOption" should become a class member var "m_MenuOption"
- compilers: You can safely remove the options you've commented in the patch btw... that's the overall goal in the end and for reference we have SVN... ;-)
- in the compilers: You are not always using GetID() to obtain the compiler's ID for loading the settings... why?
- I've removed Programs.DBG and all its references because in fact it is nowhere being used anymore since we have merged the debugger branch.
- in compiler.cpp you should add an #include <wx/xml/xml.h> for non-pch compilers

For the autodetection: I could image a core / compiler plugin base method that takes the compiler ID and implements all the different methods we have for auto-detection in one place. This way, you could get a generic compiler w/o specialisation for the auto-detection. But maybe you have a better idea already...

[Alpha]

- in the compilers: You are not always using GetID() to obtain the compiler's ID for loading the settings... why?

I plan to use GetID() for all of them, however, when Code::Blocks creates an ID, it removes "-" dash characters.  I used this as a temporary bypass while I explore to see if there is a reason compiler ID's should not contain a dash.

For the autodetection: I could image a core / compiler plugin base method that takes the compiler ID and implements all the different methods we have for auto-detection in one place. This way, you could get a generic compiler w/o specialisation for the auto-detection. But maybe you have a better idea already...

I am not completely certain I understand what you are describing.  My current plan is for the main compiler plugin to scan for compiler_*.xml files after loading all the definitions of other compilers, and for each discovered file, pass it on to compilerXML.cpp (which will contain all auto-detection routines and loading of options/regexes).  Is this the same as what you said?
Or are you saying XML based auto-detection should be part of the sdk?
Or are you saying the sdk should have some generic auto-detection methods that all compilers will call, and compilerXML.cpp will extract the necessary information from an XML file, and pass it on through these methods?

[MortenMacFly]

pass it on to compilerXML.cpp (which will contain all auto-detection routines and loading of options/regexes).

That's not what I mean, because this would not allow an "old-school" compiler easily.

Or are you saying the sdk should have some generic auto-detection methods that all compilers will call, and compilerXML.cpp will extract the necessary information from an XML file, and pass it on through these methods?

That's what I meant, but basically not part of the SDK, but the compiler plugin itself as helper functions. Auto-detection of compilers can be very specific, so it might be implemented for a single compiler (not necessarily XML based) differently. So having a "AutoDetector" class with a common interface that you can override if needed sounds most convenient to me. In the end the auto-detection has nothing to do with XML configuration (or am I wrong?!), so putting this into compilerXML doesn't seem logical to me (and only me)....?!

The same applies to the version detection - as you know we call some compilers to obtain their version to adjust the required command line settings accordingly. We didn't talk about this so far btw... any plans for this? What just comes into my mind is that this might be another use case for the <if> statements: You might want to adjust compiler options available by the version of the compiler...

I don't want to make things too complex, just to have it mentioned and discussed...

[Alpha]

pass it on to compilerXML.cpp (which will contain all auto-detection routines and loading of options/regexes).

That's not what I mean, because this would not allow an "old-school" compiler easily.

I do not believe I see how any of the changes would disallow "old-school" compilers.

So having a "AutoDetector" class with a common interface that you can override if needed sounds most convenient to me.

However, this idea seems to have more promise.  Forgive my lack of C++ knowledge, but would the way to do this use multiple inheritance:

Code

class CompilerMINGW : public Compiler, public AutoDetector

or static members in AutoDetector or something else?

The same applies to the version detection - as you know we call some compilers to obtain their version to adjust the required command line settings accordingly. We didn't talk about this so far btw... any plans for this?

Yes, I had separated out EvalXMLCondition() (although, I am not certain if it was correct to put it in globals) so more items could be added to the <if> statements with relative ease.  Two items that I will be trying to add are generic run program (true on success, false on failed to launch).  This could be used to add these types of commands only when the relevant program is available.
And version detection/comparison.  There is the easier method of checking the output of a command against a supplied regex.  The other (probably better) way would be to figure out a generic method of parsing for the version string, caching it in m_VersionString, and using some sort of generic comparison.
(One possible issue: what type of start-up cost will launching a series of external commands have?)

I plan to use GetID() for all of them, however, when Code::Blocks creates an ID, it removes "-" dash characters.  I used this as a temporary bypass while I explore to see if there is a reason compiler ID's should not contain a dash.

Upon further inspection, it appears this transformation is to create valid element names; as "-" characters are valid (except at the beginning), I have modified MakeValidID().

[MortenMacFly]

Code

class CompilerMINGW : public Compiler, public AutoDetector

Yes, this would look convenient to me. Another (simpler) option is to have the compiler class hold the autodetector and provide a single method like

Code

AutoDetectResult AutoDetect(const wxString& compiler_id /*, something else, a regex to parse the version for example?! */)
{
    CompilerAutoDetector cad(compiler_id /*, regex*/);
    return cad.AutoDetect();
}

Then you don't need multiple inheritance.

There is the easier method of checking the output of a command against a supplied regex.

This is my favourite as you see above - don't make it too complicated.

The other (probably better) way would be to figure out a generic method of parsing for the version string, caching it in m_VersionString, and using some sort of generic comparison.

Nope, I guess it will be very hard to make this generic - compilers are just too different... :-)

(One possible issue: what type of start-up cost will launching a series of external commands have?)

That is an issue, indeed. Already now we call the compilers / frontend tools at a cost. We do this with wxExecute (if I am not mistaken) although way better would be to do this threaded... However, then you have to have a state machine as it is no longer a serialised process. So we shouldn't change it for the moment as this may introduce serious (platform related) issues.

Upon further inspection, it appears this transformation is to create valid element names; as "-" characters are valid (except at the beginning), I have modified MakeValidID().

OK - great. I was wondering anyways why this could have been done...