Developer forums (C::B DEVELOPMENT STRICTLY!) > Compiler Framework Redesign
XML based compilers
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:
--- Quote from: MortenMacFly on June 27, 2012, 08:52:53 am ---- in the compilers: You are not always using GetID() to obtain the compiler's ID for loading the settings... why?
--- End quote ---
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.
--- Quote from: MortenMacFly on June 27, 2012, 08:52:53 am ---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...
--- End quote ---
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:
--- Quote from: Alpha on June 28, 2012, 03:48:07 am ---pass it on to compilerXML.cpp (which will contain all auto-detection routines and loading of options/regexes).
--- End quote ---
That's not what I mean, because this would not allow an "old-school" compiler easily.
--- Quote from: Alpha on June 28, 2012, 03:48:07 am ---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?
--- End quote ---
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... 8)
I don't want to make things too complex, just to have it mentioned and discussed... ::)
Alpha:
--- Quote from: MortenMacFly on June 28, 2012, 07:14:29 am ---
--- Quote from: Alpha on June 28, 2012, 03:48:07 am ---pass it on to compilerXML.cpp (which will contain all auto-detection routines and loading of options/regexes).
--- End quote ---
That's not what I mean, because this would not allow an "old-school" compiler easily.
--- End quote ---
I do not believe I see how any of the changes would disallow "old-school" compilers.
--- Quote from: MortenMacFly on June 28, 2012, 07:14:29 am ---So having a "AutoDetector" class with a common interface that you can override if needed sounds most convenient to me.
--- End quote ---
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
--- End code ---
or static members in AutoDetector or something else?
--- Quote from: MortenMacFly on June 28, 2012, 07:14:29 am ---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?
--- End quote ---
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?)
--- Quote from: Alpha on June 28, 2012, 03:48:07 am ---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.
--- End quote ---
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:
--- Quote from: Alpha on June 29, 2012, 03:22:59 am ---
--- Code: ---class CompilerMINGW : public Compiler, public AutoDetector
--- End code ---
--- End quote ---
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();
}
--- End code ---
Then you don't need multiple inheritance.
--- Quote from: Alpha on June 29, 2012, 03:22:59 am ---There is the easier method of checking the output of a command against a supplied regex.
--- End quote ---
This is my favourite as you see above - don't make it too complicated.
--- Quote from: Alpha on June 29, 2012, 03:22:59 am ---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.
--- End quote ---
Nope, I guess it will be very hard to make this generic - compilers are just too different... :-)
--- Quote from: Alpha on June 29, 2012, 03:22:59 am ---(One possible issue: what type of start-up cost will launching a series of external commands have?)
--- End quote ---
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.
--- Quote from: Alpha on June 29, 2012, 03:22:59 am ---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().
--- End quote ---
OK - great. I was wondering anyways why this could have been done... ::)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version