Developer forums (C::B DEVELOPMENT STRICTLY!) > Compiler Framework Redesign
XML based compilers
Alpha:
Attached is the initial conversion of all of the compilers. There is a decent chance (with so much text to convert) that I have missed/messed up something, so I would appreciate usability reports from anyone with time to test this.
My next step is to add user customization features.
darmar:
Thank you Alpha for your efforts.
I would like to add what I am missing in the current C::B implementation of compilers:
Some of compilers require options to be specified in a linker stage. But there is no possibility to have "Linker Flags" just like "Compiler Flags". Currently users can add required options in "Other linker options" window, but this is not as convenient as with flags.
Maybe it could be possible to add "Linker Flags" for "XML based compilers"?
thomas:
(Some of) the reasons why the XML idea was abandoned back then were
* XML is actually rather ill-suited for the purpose (scripting is a much better fit). Mea culpa. At that time I made the same mistake that many people make, I saw XML as great for everything. It isn't. It's great for some things, but not for all.
* It goes far beyond "some compiler switches"
* an abstraction of functionality would be needed, this needs to be properly planned and documented first, and it had better be complete (once set up, it's a pain to change again!)
* Some flags/functions are mutually exclusive on some compilers, sometimes depending on a third one, and sometimes a flag needs to be passed to another stage or requires another one being passed on a different stage
* compiler and debugger are a kind-of union
* error/warning parsing is tightly bound to the compiler as well
* The build process would have to be reworked (and probably project files as well)
* Anything else would be the same as we already have, just with a new file format
* The two people mainly involved in the planning of that beast found themselves out of time doing all that (or doing much any more either way)
* Reworking projects would be a compatibility issue, so a backwards-compatibility layer would have to be written and maintained
* Development would have to take place in a "secret branch" or we'd drown in a flood of complaints from people using nightly builds. Someone would need to merge the branch later (which out of experience I can tell is painful and takes days of work).
That said, if someone is still willing to work on this beast, great. But please do it properly, don't just tack XML onto the existing system, which frankly would be just shit (no offense intended).
Alpha:
(Warning: long post.)
--- Quote from: darmar on June 18, 2012, 09:05:43 am ---Maybe it could be possible to add "Linker Flags" for "XML based compilers"?
--- End quote ---
This is sort of already available in the current system:
--- Code: ---void AddOption(const wxString& name,
const wxString& option,
const wxString& category = _("General"),
const wxString& additionalLibs = wxEmptyString,
bool doChecks = false,
const wxString& checkAgainst = wxEmptyString,
const wxString& checkMessage = wxEmptyString);
--- End code ---
Anything in additionalLibs is sent to the linker. So in this XML system:
--- Code: ---<Option name="Strip all symbols from binary (minimizes size)"
additionalLibs="-s"/>
--- End code ---
However, this can lead to confusion because it does not explicitly mention that compiler flags can control the linker. I am considering the possibility of a "Linker Flags" window, but I am not sure if there are enough common features to warrant the extra space usage (as the functionality is, in essence, already available).
--- Quote from: thomas on June 18, 2012, 12:28:36 pm ---
* Some flags/functions are mutually exclusive on some compilers, sometimes depending on a third one, and sometimes a flag needs to be passed to another stage or requires another one being passed on a different stage
--- End quote ---
I am afraid your logic in this statement is to complicated for me to follow. If Code::Blocks current compiler system can do these, then this XML system can as well. Compilers are currently not completely decoupled into XML; only the contents of the Reset() method: m_Programs, m_Switches, m_Options, and m_Commands. These items are loaded from the compiler's XML options file (instead of being hard-coded).
--- Quote from: thomas on June 18, 2012, 12:28:36 pm ---
* The build process would have to be reworked (and probably project files as well)
* Anything else would be the same as we already have, just with a new file format
--- End quote ---
All changes are currently highly localized; the compilers' interfaces function exactly the same, the only difference is how they populate their options (pure C++ compilers are still completely valid as well).
That said, the compilers I have converted are now a hybrid of C++ (for regexps and auto-detect) and XML (for options/flags). My final (planned) step would be to write a compilerXML.cpp which would load any pure XML compilers that had been detected during start-up. (No compilers are, as of yet, dynamically loaded.)
--- Quote from: thomas on June 18, 2012, 12:28:36 pm ---[...]
don't just tack XML onto the existing system
[...]
--- End quote ---
This may have been exactly what I have done. However, I think it still holds the advantage of providing a framework to make compiler flags easily configurable. Have you had a chance to explore my implementation? - I know I am not an experienced programmer, so I would appreciate any critique on if this is even the "right" method to move forwards.
Would anyone like me to write up documentation for the current XML format? (Otherwise I will wait a bit until I am reasonably sure that it is set.)
Alpha:
This is not exactly related; in exploring the compilers, I found that the variables
--- Code: ---bool doChecks
const wxString& checkAgainst
const wxString& checkMessage
--- End code ---
have no effect. I assume that they were planned, but no one finished the implementation. If I were to implement this, should I bundle it with my XML compiler patch, or should I make it directly against the trunk?
Edit: Never mind; against trunk.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version