Developer forums (C::B DEVELOPMENT STRICTLY!) > Compiler Framework Redesign
XML based compilers
MortenMacFly:
--- Quote from: thomas on June 18, 2012, 12:28:36 pm ---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).
--- End quote ---
Well Thomas, I got you point, but please: Don't request a re-build of the core from a single person involved just recently.
And I clearly disagree with you here: What I think completely sucks is that these options are hard-coded inside each compiler. So we basically need to re-build everything if just a single option changes. Also, some compilers are basically the same just they differ in some options. So you could easily go one step further (as Alpha suggested already) and have a "generic" compiler that loads and configures itself with such configuration. This will definitely work so some extend.
Also, if you change the advanced options of the compiler they are already XML based, just inside the C::B config where they not belong to IMHO. Thus, making all options XML based is just consequent.
So: I agree that there may be the ultimate solution possible, but we don't have time and resources for it ATM. Nevertheless the approach proposed here is a huge step in the right direction, clearly, so we should go for it. Furthermore I don't think the script based approach will be a good idea at the moment. The scripting engine is the show-stopper #1 for the 64 bit build of C::B as SQPlus was abandoned and we have to maintain it ourself. But this is such a low-level stuff that you need an own team of devs just for that. already, meanwhile you cannot even update the underlying squirrel anymore due the massively out-dated SQPlus layer. If we make everything script based we end-up nowhere sooner or later, IMHO.
thomas:
Well, if nothing helps, we can still move back to Angelscript, which is well supported. Ironically, the reason why we abandoned Angelscript back then was that it didn't do 64 bits at that time... ;D
The thing about scripting is you could not only concatenate some strings, but also do logic inside them. In fact, not only the composition of the options dialog, but the entire build process could be a script which calls some native SDK functions (one would need a well-defined interface, of course). Not much unlike the project wizards (yep, those that I hate so much) work. What I'd wish for is nothing else but the "generic compiler" that you talked about earlier. Except with scripting it would certainly work, as a script can trivially do "just anything", and with XML I see the task of making something that works for all as rather difficult.
Now XML is mighty fine for configuring a few strings, but the logic is still all hardcoded, and the way compiler options are handled is poor at best. You know I'm no friend of "too much darn smartness", but compiler options in Code::Blocks aren't smart at all. You can for example select "do not optimize" together with all levels of optimization, all at the same time (same goes for warnings), you can select a dozen architectures at the same time, and you can generate debug info and strip at the same time. Certainly you can expect a programmer to somewhat know what he's doing, but how often does it happen to you that you accidentially strip your debug info and wonder why the debugger doesn't come up (if it doesn't ever happen to you, you're provably more intelligent than I am, I have this about once every other week). In any case, it wouldn't hurt if the user interface was a bit clearer. Alas, this is darn hard to hardcode.
What I'm fearing is that if this kind of works (even if it works only just a little bit better than what we have now) it will stay like this for the next decade. ::)
If only I had the time... :(
Alpha:
--- Quote from: thomas on June 19, 2012, 02:05:30 am ---You know I'm no friend of "too much darn smartness", but compiler options in Code::Blocks aren't smart at all. You can for example select "do not optimize" together with all levels of optimization, all at the same time (same goes for warnings), you can select a dozen architectures at the same time, and you can generate debug info and strip at the same time. Certainly you can expect a programmer to somewhat know what he's doing, but how often does it happen to you that you accidentially strip your debug info and wonder why the debugger doesn't come up (if it doesn't ever happen to you, you're provably more intelligent than I am, I have this about once every other week). In any case, it wouldn't hurt if the user interface was a bit clearer. Alas, this is darn hard to hardcode.
--- End quote ---
Now that you mention it, I had already created the ability to fix this in my local version with:
--- Code: ---struct CompOption
{
// following comments are an example of an option
wxString name; // "Profile code"
wxString option; // "-pg"
wxString additionalLibs;// "-lgmon"
bool enabled; // true/false
wxString category; // "Profiling"
bool doChecks; // true/false
wxString checkAgainst; // "-O -O1 -O2 -O3 -Os" (will check for these options and if any of them is found, will display the following message)
wxString checkMessage; // "You have optimizations enabled. This is Not A Good Thing(tm) when producing debugging symbols..."
wxString supersedes; // "-O -O1 -O2" (will check for these options and disable any of them that are found)
bool exclusive; // true/false (will ensure that only one item in this category is ever selected)
};
--- End code ---
and
--- Code: ---void CompilerOptionsDlg::OnOptionToggled(wxCommandEvent& event)
{
wxCheckListBox* list = XRCCTRL(*this, "lstCompilerOptions", wxCheckListBox);
int sel = event.GetInt();
CompOption* copt = m_Options.GetOptionByName(list->GetString(sel));
if (copt)
{
copt->enabled = list->IsChecked(sel);
if (copt->enabled)
{
if (copt->doChecks)
{
wxArrayString check = GetArrayFromString(copt->checkAgainst, _T(" "));
for (size_t i = 0; i < check.Count(); i++)
{
CompOption* against = m_Options.GetOptionByOption(check[i]);
if (against && against->enabled)
{
AnnoyingDialog dlg(_("Compiler options conflict"),
copt->checkMessage,
wxART_INFORMATION,
AnnoyingDialog::OK,
wxID_OK);
dlg.ShowModal();
break;
}
}
}
if (copt->supersedes != wxEmptyString)
{
wxArrayString supersede = GetArrayFromString(copt->supersedes, _T(" "));
for (size_t i = 0; i < supersede.Count(); i++)
{
for (size_t j = 0; j < m_Options.GetCount(); j++)
{
if (copt != m_Options.GetOption(j) &&
supersede[i] == m_Options.GetOption(j)->option)
{
list->Check(j, false);
m_Options.GetOption(j)->enabled = false;
}
}
}
}
if (copt->exclusive)
{
for (size_t i = 0; i < m_Options.GetCount(); i++)
{
if (copt != m_Options.GetOption(i) &&
copt->category == m_Options.GetOption(i)->category)
{
list->Check(i, false);
m_Options.GetOption(i)->enabled = false;
}
}
}
}
}
m_bDirty = true;
} // OnOptionToggled
--- End code ---
(I implemented doChecks and added supersedes and exclusive. I did not update the current compilers to take advantage of this functionality, however my quick test with the XML compilers worked beautifully - the next patch I upload will contain these and (hopefully) dynamically configurable flags.)
What I am not currently sure about is if it is better (and in which cases) to show a warning dialog, and when to just automatically check/uncheck the conflicting options.
--- Quote from: thomas on June 19, 2012, 02:05:30 am ---Well, if nothing helps, we can still move back to Angelscript, which is well supported. Ironically, the reason why we abandoned Angelscript back then was that it didn't do 64 bits at that time... ;D
--- End quote ---
With respects to scripting, I am curious if anyone has ever discussed the pros/cons of Python?
oBFusCATed:
--- Quote from: Alpha on June 19, 2012, 04:19:21 am ---With respects to scripting, I am curious if anyone has ever discussed the pros/cons of Python?
--- End quote ---
Python is not made for embedding, it is their agenda that the applications should be written in python, not extended by python.
It is doable but the API is pretty low level or we need to require Boost.Python, which is mighty heavy.
Also shipping python on windows will be problematic.
In my opinion current scripting in C::B is pretty bad, because SQPlus is mighty stupid. I've tried to add some scripting for the debugger and failed quite miserably :(
Also the docs for squirrel are not helping much, as they are written for someone knowing what he is doing, not for someone who is new to it and scripting.
MortenMacFly:
--- Quote from: oBFusCATed on June 19, 2012, 10:14:47 am ---In my opinion current scripting in C::B is pretty bad, because SQPlus is mighty stupid. I've tried to add some scripting for the debugger and failed quite miserably :(
--- End quote ---
We are becoming slightly off-topic, however...:
I think Scrat (http://scrat.sourceforge.net/) would be another option for a replacement of SQPlus. But as Thomas said, if AngelScript is still alive, actively developed (and supported) and supports 64 bit we might have done a wrong choice the time back... :-\
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version