Developer forums (C::B DEVELOPMENT STRICTLY!) > Compiler Framework Redesign
XML based compilers
Jenna:
--- Quote from: MortenMacFly on July 31, 2012, 06:44:28 am ---@Jens: Do you / Did you try that "beast" under Linux already?
--- End quote ---
Yes, but no really deep tests.
At least it works fine to compile and debug C::B and the contrib-plugins and some other (makefile-based) projects (wxWidgets trunk with gtk2 and gtk3 and aui and notebooks samples).
All compiled with gcc, but makefile-based projects should not be changed (much?) anyway, I think.
oBFusCATed:
--- Quote from: Alpha on July 31, 2012, 03:15:49 am ---Compiler logging tweaks:
* Clear progress bar on abort
* Remove tabs from build messages (so they do not print as squares)
* Auto adjust build message size
--- End quote ---
Keep in mind that changing the interface of public for the SDK class requires an increase of the SDK version (the macros at the top of the cbplugin.h file).
Alpha:
--- Quote from: oBFusCATed on July 31, 2012, 08:40:54 am ---Keep in mind that changing the interface of public for the SDK class requires an increase of the SDK version (the macros at the top of the cbplugin.h file).
--- End quote ---
Yes (and I would assume that there are multiple other changes in this branch that would also require an SDK version increment), however, as this is a branch, would it not be better to only have a single increment upon merging with the trunk?
Another logging tweak and the removal of a GCC 4.7 warning:
--- Code: ---Index: src/sdk/compiler.cpp
===================================================================
--- src/sdk/compiler.cpp (revision 8176)
+++ src/sdk/compiler.cpp (working copy)
@@ -1013,11 +1013,9 @@
}
else if (node->GetName() == wxT("RegEx"))
{
- CompilerLineType clt;
wxString tp = node->GetAttribute(wxT("type"), wxEmptyString);
- if (tp == wxT("normal"))
- clt = cltNormal;
- else if (tp == wxT("warning"))
+ CompilerLineType clt = cltNormal;
+ if (tp == wxT("warning"))
clt = cltWarning;
else if (tp == wxT("error"))
clt = cltError;
Index: src/plugins/compilergcc/directcommands.cpp
===================================================================
--- src/plugins/compilergcc/directcommands.cpp (revision 8176)
+++ src/plugins/compilergcc/directcommands.cpp (working copy)
@@ -583,8 +583,8 @@
if (!fileMissing.IsEmpty())
{
wxString warn;
- warn.Printf(_("WARNING: Target '%s': Unable to resolve %d external dependencies:"),
- target->GetFullTitle().wx_str(), fileMissing.Count());
+ warn.Printf(_("WARNING: Target '%s': Unable to resolve %d external dependenc%s:"),
+ target->GetFullTitle().wx_str(), fileMissing.Count(), wxString(fileMissing.Count() == 1 ? _("y") : _("ies")).wx_str());
ret.Add(wxString(COMPILER_SIMPLE_LOG) + warn);
for (size_t i=0; i<fileMissing.Count(); i++)
ret.Add(wxString(COMPILER_SIMPLE_LOG) + fileMissing[i]);
--- End code ---
oBFusCATed:
--- Quote from: Alpha on July 31, 2012, 11:01:12 pm ---Yes (and I would assume that there are multiple other changes in this branch that would also require an SDK version increment), however, as this is a branch, would it not be better to only have a single increment upon merging with the trunk?
--- End quote ---
For me it is better to increment the sdk version number with every break of the api, you can't be sure if there are users running your code and if they have custom plugins or not.
MortenMacFly:
--- Quote from: oBFusCATed on August 01, 2012, 12:05:47 am ---For me it is better to increment the sdk version number with every break of the api, you can't be sure if there are users running your code and if they have custom plugins or not.
--- End quote ---
Branches are for people knowing what they do. When merged, the SDK major version will increase anyways due to the massive change (as it was with the debugger re-factoring). But in principle you are right... ::)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version