Developer forums (C::B DEVELOPMENT STRICTLY!) > Compiler Framework Redesign
XML based compilers
Alpha:
--- Quote from: MortenMacFly on June 26, 2012, 08:57:17 am ---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.
--- End quote ---
Oops; I forgot to refresh the categories when a new one is added.
--- Quote from: MortenMacFly on June 26, 2012, 09:05:05 am ---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?
--- End quote ---
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.
--- Quote from: MortenMacFly on June 26, 2012, 08:57:17 am ---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.
--- End quote ---
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:
--- Quote from: Alpha on June 26, 2012, 03:08:07 pm ---The modified XML is stored in the user profile, so it is very unlikely to shift platforms.
--- End quote ---
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.
--- Quote from: Alpha on June 26, 2012, 03:08:07 pm ---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.
--- End quote ---
Great... I'll wait patiently... 8)
Alpha:
--- Quote from: MortenMacFly on June 26, 2012, 05:26:52 pm ---
--- Quote from: Alpha on June 26, 2012, 03:08:07 pm ---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.
--- End quote ---
Great... I'll wait patiently... 8)
--- End quote ---
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).
--- Quote from: MortenMacFly on June 26, 2012, 05:26:52 pm ---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?
--- End quote ---
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:
--- Quote from: Alpha on June 27, 2012, 04:18:43 am ---Here it is.
--- End quote ---
Nice... will try ASAP...
--- Quote from: Alpha on June 27, 2012, 04:18:43 am ---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.)
--- End quote ---
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 "_".
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version