Task:
- Make compiler options more flexible
The compiler options are added like:Codem_Options.AddOption(description, unique_compiler_key, category);
- Make this available through an XML settings file
- Design/implement an UI to easily edit these options
- Probably allow to derive form an other's compiler settings
My current idea is to have a right-click menu with:
- You/we should consider a simple UI in the end where the user can adjust these options as desired so they become really flexible. Just keep in mind if designing interfaces for example.
New flag...
Modify flag...
Delete flag
I had selected wxXml because it had enough features for my purposes, and so that I did not have to worry about converting wxStrings. Is it fine to leave as-is, or should I switch to TinyXML?
- I would have preferred to see using TinyXML the persistence layer as we do it with any other XML based options files, but this might not be so important (I recall when we decided to go for TinyXML the XML layer in wxWidgets was not that powerful.)
My current idea is to have a right-click menu with:That's an easy way for a first step, sure.CodeNew flag...
Modify flag...
Delete flag
I had selected wxXml because it had enough features for my purposes, and so that I did not have to worry about converting wxStrings. Is it fine to leave as-is, or should I switch to TinyXML?Well as I said - wxXml has changes a lot, so if you have all functions you need, I'm fine with it.
Maybe it could be possible to add "Linker Flags" for "XML based compilers"?This is sort of already available in the current system:
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);
<Option name="Strip all symbols from binary (minimizes size)"
additionalLibs="-s"/>
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).
- 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
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).
- 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
[...]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.
don't just tack XML onto the existing system
[...]
bool doChecks
const wxString& checkAgainst
const wxString& checkMessage
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).Well Thomas, I got you point, but please: Don't request a re-build of the core from a single person involved just recently.
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.Now that you mention it, I had already created the ability to fix this in my local version with:
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)
};
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
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... ;DWith respects to scripting, I am curious if anyone has ever discussed the pros/cons of Python?
With respects to scripting, I am curious if anyone has ever discussed the pros/cons of Python?Python is not made for embedding, it is their agenda that the applications should be written in python, not extended by python.
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 :(We are becoming slightly off-topic, however...:
My current idea is to have a right-click menu with:I can create this menu, but I am not certain how I am supposed to attach it. The popup will belong to a wxCheckListBox (XRCID: "lstCompilerOptions"). Does the connection belong in an event table? Should I be calling Connect()? (Also, is this (http://wiki.wxwidgets.org/WxMenu) the suggested way to use it?)CodeNew flag...
Modify flag...
Delete flag
I think Scrat would be another option for a replacement of SQPlus.Sqrat looks nice, it's very straightforward to use, feature-complete, header-only.
Completed patch finally available.I forgot to mention; this patch includes:
If you want to waste some time in the evening playing with it, I can share the project. Maybe I'm only just too stupid, and you can figure it out.To be honest I never tried myself, just found this link when looking for a more up-to-date SQPlus. So sure, gimme gimme... (I am back btw...).
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... ;DThis is really fun and honestly I don't get it: Did we ever try 64 bit with scripting at that time seriously? Because then we would have found out easily that we are doomed with SQPlus. I wonder if it is working straight forward on Linux though... on Windows its very bad and it gets even worse as new (more strict) compilers hit the floor.
Preliminary documentation (http://wiki.codeblocks.org/index.php?title=Compiler_options_file) is done.Huh - the first pach provider with a documentation! That's Wohooo! ;-)
Sqrat test attached, no external dependencies. Unzip, doubleclick, hit "build".Same crash here, it seems the VM pointer is zero, therefore compilation fails and throws (in sq_compile)...
Harhar, funny. Solved it. All you need to do is to set the default VM before you do the table stuff (all what's in your "try..." statements. So just add this line after "sq_seterrorhandler(vm);":Sqrat test attached, no external dependencies. Unzip, doubleclick, hit "build".Same crash here, it seems the VM pointer is zero, therefore compilation fails and throws (in sq_compile)...
Sqrat::DefaultVM::Set(vm);
2.) I think later on we can/should transfer the regexes and advanced compiler options to the XML file, too. For this, it needs an interface to the configmanager.What are these other advanced compiler options? I think the XML files currently contain all options except for the regexes.
...I just saw: Did you realise SVN revision 8060? Is this already integrated?Yes (and it was very fast to do; adding this new flag to options_common_warnings.xml put it in the whole GNU family).
(I am no compiler expert, so I only added these interactions where they were obvious. Feel free to let me know of any flag interactions I have missed/messed up.)
- Warning messages if multiple compiler options are unwise to use together (but still legal)
- Automatic disabling of conflicting compiler options (for example, enabling debug symbols automatically disables strip)
What are these other advanced compiler options?They are for example in default.conf:
Question: The only condition that <if></if> blocks currently recognize is platform - are there any other conditions that would be made use of during the loading of a compiler?One thing I could think of is an if-statement to check for a compiler version... not sure how to handle this at startp w/o running the compiler though.
Is it correct for me to assume that the GCC regexes (located in compilerMINGW.cpp) are applicable to all supported (C/C++) GCC variants (ARM, TriCore, ...)?I think it isn't wrong in a first place, but to be sure you'd have to ask the compiler guys developing these. I never worked with ARM/TriCore compilers.
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.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?
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.Oops; I forgot to refresh the categories when a new one is added.
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?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 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.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.
The modified XML is stored in the user profile, so it is very unlikely to shift platforms.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.
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.Great... I'll wait patiently... 8)
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).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.Great... I'll wait patiently... 8)
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?Yes. (At least, this is what it is supposed to do...)
Here it is.Nice... will try ASAP...
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.)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 "_".
- in the compilers: You are not always using GetID() to obtain the compiler's ID for loading the settings... why?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.
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...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?
pass it on to compilerXML.cpp (which will contain all auto-detection routines and loading of options/regexes).That's not what I mean, because this would not allow an "old-school" compiler easily.
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?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)....?!
I do not believe I see how any of the changes would disallow "old-school" compilers.pass it on to compilerXML.cpp (which will contain all auto-detection routines and loading of options/regexes).That's not what I mean, because this would not allow an "old-school" compiler easily.
So having a "AutoDetector" class with a common interface that you can override if needed sounds most convenient to me.However, this idea seems to have more promise. Forgive my lack of C++ knowledge, but would the way to do this use multiple inheritance:
class CompilerMINGW : public Compiler, public AutoDetector
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?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 (http://wiki.codeblocks.org/index.php?title=Adding_support_for_non_C/C%2B%2B_files_to_the_build_system) only when the relevant program is available.
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.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().
Yes, this would look convenient to me. Another (simpler) option is to have the compiler class hold the autodetector and provide a single method likeCodeclass CompilerMINGW : public Compiler, public AutoDetector
AutoDetectResult AutoDetect(const wxString& compiler_id /*, something else, a regex to parse the version for example?! */)
{
CompilerAutoDetector cad(compiler_id /*, regex*/);
return cad.AutoDetect();
}
There is the easier method of checking the output of a command against a supplied regex.This is my favourite as you see above - don't make it too complicated.
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.Nope, I guess it will be very hard to make this generic - compilers are just too different... :-)
(One possible issue: what type of start-up cost will launching a series of external commands have?)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.
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().OK - great. I was wondering anyways why this could have been done... ::)
Another (simpler) option is to have the compiler class hold the autodetector and provide a single methodOK, I will experiment with this. Would you happen to know if this technique is used elsewhere in Code::Blocks, so that I could examine it?
[...]
Would you happen to know if this technique is used elsewhere in Code::Blocks, so that I could examine it?Mmmmh... not to my knowledge. It would be a tooling class. So it its easier for you to derive from - just go that way. In the end from an interface point of view its the same.
I believe I will be busy for a few days, so I am not certain when my next patch will come.No üroblem, leaves more time for me to test. BTW: already now I have used it a lot w/o issues. Just the patch needs tweaks to compile w/o PCH and on wx 2.9.x.
I believe I will be busy for a few days, so I am not certain when my next patch will come.... maybe that was a bit more than a few days...
- compileroptionsdlg: The global var "menuOption" should become a class member var "m_MenuOption"By the way, this change causes the passing on of the event id to mysteriously fail (no errors are raised, and according to gdb, m_MenuOption reverts -1 when OnFlagsPopupClick() returns).
Does anyone have specific example flags that should be hidden if the compiler is detected as a certain version?Certainly the platform flags usually need attention. Also, -std=c++0x and -std=c++11 and some warnings (like -Weffc++) have not always been available.
By the way, this change causes the passing on of the event id to mysteriously fail (no errors are raised, and according to gdb, m_MenuOption reverts -1 when OnFlagsPopupClick() returns).Huh? How weird is that?! Maybe we are overriding a member variable with the same name of a base class?! I'll have a look.
However, it does work if I make it a static class member. Would this still be the preferred method?...in the mean time: Yes. :-)
Now that options are almost all loaded with the same code, is it fine to make Compiler::Reset() and Compiler::LoadDefaultRegExArray() non-pure virtuals?Depends on what you mean with almost here...?! If its not the same, shouldn't it remain virtual because in that case a compiler needs to implement it?!
They would still remain virtualNow that options are almost all loaded with the same code, is it fine to make Compiler::Reset() and Compiler::LoadDefaultRegExArray() non-pure virtuals?Depends on what you mean with almost here...?! If its not the same, shouldn't it remain virtual because in that case a compiler needs to implement it?!
virtual void Reset();
virtual void Reset() = 0;
void CompilerMSVC8::LoadDefaultRegExArray()
{
m_RegExes.Clear();
LoadRegExArray(GetID());
}
void CompilerMSVC8::Reset()
{
m_Options.ClearOptions();
LoadDefaultOptions(GetID());
LoadDefaultRegExArray();
m_CompilerOptions.Clear();
m_LinkerOptions.Clear();
m_LinkLibs.Clear();
m_CmdsBefore.Clear();
m_CmdsAfter.Clear();
}
I've created a branch for you work here:Thank you (the patches against the trunk were becoming almost unreadable due to size). I have finished merging, and will be doing a few tests; the next patch should come soon.
They would still remain virtualAh - that makes sense, sure.Codejust not pure vitrualvirtual void Reset();
Codevirtual void Reset() = 0;
By almost, I mean all of the LoadDefaultRegExArray() look likeYes, is seems feasible that they are in base now. Maybe we can do it even easier: Reset calls ResetPrivate() which is the virtual method you need to override if you need to do something special and in its default implementation it does nothing (same for LoadXXX). This way, compilers were "forced" to use the default "Reset" (which is good I think) but still can do something special. To soften the requirements we could stick with the virtual Reset method. Although it would be not too bad to make Reset even non-virtual and protected in that case.
[...]
and most of the Reset() look like
Patch available (against XML branch).For the record: Applies flawlessly in the branch. Nice! (Not compiled in / tested though...)
Maybe we can do it even easier: Reset calls ResetPrivate() which is the virtual method you need to override if you need to do something special and in its default implementation it does nothing (same for LoadXXX). This way, compilers were "forced" to use the default "Reset" (which is good I think) but still can do something special. To soften the requirements we could stick with the virtual Reset method. Although it would be not too bad to make Reset even non-virtual and protected in that case.Almost everything I know about program design has been self taught through a combination of the internet, and half-finished books; I do not think I know what is the best option here.
What do you think?
For the record: Applies flawlessly in the branch. Nice!Go WinMerge (http://sourceforge.net/projects/winmerge/)! :)
When running with debug log (and therefore warnings) enabled, now I get tons of warnings, that the command issued to detect the compiler could not be executed.Oops... I will deal with that.
Index: src/sdk/resources/editor_configuration.xrc
===================================================================
--- src/sdk/resources/editor_configuration.xrc (revision 8138)
+++ src/sdk/resources/editor_configuration.xrc (working copy)
@@ -465,7 +465,7 @@
<flag>wxALL|wxEXPAND|wxALIGN_LEFT|wxALIGN_TOP</flag>
<border>4</border>
</object>
- <label>Colouring andf highlighting options</label>
+ <label>Colouring and highlighting options</label>
<orient>wxVERTICAL</orient>
</object>
<flag>wxALL|wxEXPAND|wxALIGN_LEFT|wxALIGN_TOP</flag>
Adding to the previous patch:Nice, especially the "welcome" of the XML compiler.
[...]
Do you have an easy way/tool to convert/add this?The absolute easiest way is to register it in compilergcc.cpp as a normal compiler, then (build and) launch Code::Blocks, open the compiler settings, create (and delete) a new flag for the compiler (to make it think it has changed), and click OK. This will generate a fully usable file in your user data folder.
Did you try what happens if you create a copy of a compiler? Dos that still work?It does work except that copied compilers do not load user customized sets of compiler flags; this fixes it.
It does work except that copied compilers do not load user customized sets of compiler flags; this fixes it.So... to summarise: It works pretty well and I don't see major drawbacks. It only needs testing on Linux.
From my perspective: Linux testing,I just committed fixes to the linux project-file and the automake-system.
I just committed fixes to the linux project-file and the automake-system.Sorry, I think this brakes the build system again.
I just committed fixes to the linux project-file and the automake-system.Sorry, I think this brakes the build system again.
Index: src/plugins/compilergcc/compilerXML.h
===================================================================
--- src/plugins/compilergcc/compilerXML.h (revision 8155)
+++ src/plugins/compilergcc/compilerXML.h (working copy)
@@ -3,7 +3,7 @@
#include <compiler.h>
-#include <wx/string.h>
+class wxString;
class CompilerXML : public Compiler
{
@@ -28,7 +28,7 @@
none
};
- bool AddPath(const wxString& pth, int sm, int rmDirs = 0);
+ bool AddPath(const wxString& pth, SearchMode sm, int rmDirs = 0);
wxString m_fileName;
};
Index: src/plugins/compilergcc/compilerXML.cpp
===================================================================
--- src/plugins/compilergcc/compilerXML.cpp (revision 8155)
+++ src/plugins/compilergcc/compilerXML.cpp (working copy)
@@ -1,10 +1,12 @@
#include <sdk.h>
-#include <wx/arrstr.h>
-#include <wx/filefn.h>
-#include <wx/regex.h>
+#ifndef CB_PRECOMP
+ #include <wx/arrstr.h>
+ #include <wx/filefn.h>
+ #include <wx/regex.h>
+ #include <wx/xml/xml.h>
+#endif // CB_PRECOMP
#include <wx/textfile.h>
-#include <wx/xml/xml.h>
#ifdef __WXMSW__ // for wxRegKey
#include <wx/msw/registry.h>
#endif // __WXMSW__
@@ -243,7 +245,7 @@
return adrGuessed;
}
-bool CompilerXML::AddPath(const wxString& pth, int sm, int rmDirs)
+bool CompilerXML::AddPath(const wxString& pth, SearchMode sm, int rmDirs)
{
wxFileName fn(pth + wxFILE_SEP_PATH);
fn.Normalize(wxPATH_NORM_ENV_VARS|wxPATH_NORM_DOTS);
Maybe this is a slightly tidier way to fix PCH for compilerXML.cpp:That is wrong. You cannot use a fwd decl if you are using an instance of wxString. Its only valid when using only const refs or pointers.Code-#include <wx/string.h>
+class wxString;
[...]
wxString m_fileName;
...although this is correct. :-)CodeIndex: src/plugins/compilergcc/compilerXML.cpp
===================================================================
--- src/plugins/compilergcc/compilerXML.cpp (revision 8155)
+++ src/plugins/compilergcc/compilerXML.cpp (working copy)
@@ -1,10 +1,12 @@
#include <sdk.h>
-#include <wx/arrstr.h>
-#include <wx/filefn.h>
-#include <wx/regex.h>
+#ifndef CB_PRECOMP
+ #include <wx/arrstr.h>
+ #include <wx/filefn.h>
+ #include <wx/regex.h>
+ #include <wx/xml/xml.h>
+#endif // CB_PRECOMP
#include <wx/textfile.h>
-#include <wx/xml/xml.h>
#ifdef __WXMSW__ // for wxRegKey
#include <wx/msw/registry.h>
#endif // __WXMSW__
@@ -243,7 +245,7 @@
return adrGuessed;
}
-bool CompilerXML::AddPath(const wxString& pth, int sm, int rmDirs)
+bool CompilerXML::AddPath(const wxString& pth, SearchMode sm, int rmDirs)
{
wxFileName fn(pth + wxFILE_SEP_PATH);
fn.Normalize(wxPATH_NORM_ENV_VARS|wxPATH_NORM_DOTS);
Should I do the linux fixes, or are you already working on it ?I would prefer you do it. for me it would be a "Blindflug" as I am not under Linux.
Its only valid when using only const refs or pointers.Partially true, because normal (non-const) references are forward declarable, too.
Should I do the linux fixes, or are you already working on it ?I would prefer you do it. for me it would be a "Blindflug" as I am not under Linux.
I must have been working without actually thinking... I completely did not see that variable (though I do not know how, as I was the one who wrote it :-[).Maybe this is a slightly tidier way to fix PCH for compilerXML.cpp:That is wrong. You cannot use a fwd decl if you are using an instance of wxString.Code-#include <wx/string.h>
+class wxString;
[...]
wxString m_fileName;
I cannot think of any major changes/additions (other than possibly converting a few more interfaces to pure XML)I agree. The fact that you converted so many compiler already is also a proof f the concept. 8)
Index: src/sdk/loggers.cpp
===================================================================
--- src/sdk/loggers.cpp (revision 8175)
+++ src/sdk/loggers.cpp (working copy)
@@ -340,7 +340,7 @@
control->Thaw();
}
-void ListCtrlLogger::Append(const wxArrayString& colValues, Logger::level lv)
+void ListCtrlLogger::Append(const wxArrayString& colValues, Logger::level lv, int autoSize)
{
if (!control)
return;
@@ -353,6 +353,8 @@
int idx = control->GetItemCount() - 1;
for (size_t i = 1; i < colValues.GetCount(); ++i)
control->SetItem(idx, i, colValues[i]);
+ if (autoSize != -1)
+ control->SetColumnWidth(autoSize, wxLIST_AUTOSIZE);
control->Thaw();
}
Index: src/plugins/compilergcc/compilergcc.cpp
===================================================================
--- src/plugins/compilergcc/compilergcc.cpp (revision 8175)
+++ src/plugins/compilergcc/compilergcc.cpp (working copy)
@@ -3382,7 +3382,9 @@
wxArrayString errors;
errors.Add(filename);
errors.Add(line);
- errors.Add(msg);
+ wxString msgFix = msg;
+ msgFix.Replace(wxT("\t"), wxT(" "));
+ errors.Add(msgFix);
Logger::level lv = Logger::info;
if (lt == cltError)
@@ -3390,8 +3392,7 @@
else if (lt == cltWarning)
lv = Logger::warning;
- m_pListLog->Append(errors, lv);
-// m_pListLog->GetListControl()->SetColumnWidth(2, wxLIST_AUTOSIZE);
+ m_pListLog->Append(errors, lv, 2);
// add to error keeping struct
m_Errors.AddError(lt, prj, filename, line.IsEmpty() ? 0 : atoi(wxSafeConvertWX2MB(line)), msg);
@@ -3642,6 +3643,8 @@
LogWarningOrError(cltNormal, 0, wxEmptyString, wxEmptyString,
wxString::Format(_("=== Build finished: %s ==="), msg.wx_str()));
SaveBuildLog();
+ if (!Manager::IsBatchBuild() && m_pLog->progress)
+ m_pLog->progress->SetValue(0);
}
else
{
@@ -3665,9 +3668,6 @@
Manager::Get()->ProcessEvent(evtSwitch);
m_pListLog->FocusError(m_Errors.GetFirstError());
- // Build is not completed, so clear the progress bar
- if (m_pLog->progress)
- m_pLog->progress->SetValue(0);
}
else
{
Index: src/include/loggers.h
===================================================================
--- src/include/loggers.h (revision 8175)
+++ src/include/loggers.h (working copy)
@@ -136,7 +136,7 @@
virtual void CopyContentsToClipboard(bool selectionOnly = false);
virtual void UpdateSettings();
virtual void Append(const wxString& msg, Logger::level lv = info);
- virtual void Append(const wxArrayString& colValues, Logger::level lv = info);
+ virtual void Append(const wxArrayString& colValues, Logger::level lv = info, int autoSize = -1);
virtual size_t GetItemsCount() const;
virtual void Clear();
virtual wxWindow* CreateControl(wxWindow* parent);
@Jens: Do you / Did you try that "beast" under Linux already?
Compiler logging tweaks: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).
- Clear progress bar on abort
- Remove tabs from build messages (so they do not print as squares)
- Auto adjust build message size
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).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?
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]);
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?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.
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.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... ::)
Maybe to clarify a few bits:
You have to differ between compiler settings like flags. Those are in XML files in C::B\share\CodeBlocks\compilers. Those are nicely grouped, i.e. common settings between compilers are shared.
If you change compiler flags (like adding a compiler flag in the compiler options) a copy of that XML file is created in C::B\share\CodeBlocks\compilers which superseeds the old one, but also includes ALL shared (common) parts.
Then you have user settings, like concrete path's which are mapped to the compiler's global settings available but are an "instance". Those are in default.conf and remain there (and belong there, too).
BTW: Alpha did a very nice WiKi article explaining the concept here:
http://wiki.codeblocks.org/index.php?title=Compiler_options_file
I meanwhile found the following issues: Compiler ID's have indeed changed for:
armelfgcc -> arm_elf_gcc
avrgcc -> avr_gcc
msp430gcc -> msp430_gcc
ppcgcc -> ppc_gcc
tricoregcc -> tricore_gcc
I think I know why, because in the initial algorithm to compile the ID there was a comment stating that to make a compiler ID valid XML all underscores need to be removed. This is wrong (however), so Alpha asked me to remove that check and I said yes. That's why now there is an underscore. Actually this is more correct, but causes trouble. The solution here is, also to check for the old style, when reading, but write the new style. (to project files).
void Compiler::ReloadOptions()
{
if (ConfigManager::LocateDataFile(wxT("compilers/options_") + GetID() + wxT(".xml"), sdDataUser | sdDataGlobal).IsEmpty())
return; // Do not clear if the options cannot be reloaded
m_Options.ClearOptions();
LoadDefaultOptions(GetID());
LoadDefaultRegExArray();
}
This patch should (I cannot be certain, because I only tested it on Windows): [...]Thanks for the fast response! I had a a look into it and I see this snippet in compiler.cpp (and compilerfactory.cpp):
AutoDetectResult CompilerLCC::AutoDetectInstallationDir()
{
#ifdef __WXMSW__
...
wxString compiler; compiler << wxFILE_SEP_PATH << _T("bin") << wxFILE_SEP_PATH << m_Programs.C;
...
#endif // __WXMSW__
...
return wxFileExists(m_MasterPath+compiler) ? adrDetected : adrGuessed;
build is broken :Try again after SVN update.
The checkbox to allow non-platform compilers needs a restart to have an effect.Maybe to clarify, where this comes from: I recently discussed with Alpha the following:
Something else in between: I read this:But yes, the restart should be clarified.
http://www.orbiterwiki.org/wiki/Free_Compiler_Setup_Under_Linux
And I had an idea: Whats missing for the compiler but would really be useful for cross compiling is that you could setup via Config/API (!) if a compiler is attached/active under the current platform. [...]
Didn't you mean to replace "_" (underscore) with "" (empty)? Here, you replace "-" (minus), but IMHO that id not present in the IDs anyways...?! (See my previous post about the ID's). Why do you do so?Although "-" (minus) is valid as an XML element name, TiXml apparently decides that they should be synonymous with, and written as "_" (underscores). The change I made to the ID creation algorithm allows "-" to be used internally (I mostly did this for the cosmetic purposes of naming the XML files: options_arm-elf-gcc.xml is more recognizable than options_armelfgcc.xml, which is what it would have been under the previous system).
This should be stated in the label, or if possible the compiler should be reloaded automatically.This patch causes the compilers to be reloaded (if chkNonPlatComp changed) when the settings dialog is dismissed; I did not do this at first because I was worried about possible side effects, however it seemed to function as expected in my few test cases.
By the way, am I correct in assuming the revert of this means that a visible note is preferred over a tool tip?
- Switch the right-click note to a tool tip (this is less obtrusive, but should still alert the user to the editing capability)
By the way, am I correct in assuming the revert of this means that a visible note is preferred over a tool tip?For such important things, yes. Most people don'T wait long enough that the tooltip shows. Also, there are platforms where there is no tooltip. So tooltip should really be a "tip", not to worry about if you don't know it.
Or the best options (three) - separate the c and c++ compilers in different entries/compilers :)Why would you do that? MSVC for example is one compiler for all. We shouldn't split up things like that. I think grouping visually is fair enough. And event hat I believe won't be used by most of the people. To be honest to me (and only me) it sounds a bit like an overkill. But maybe just because I fail to see the benefit for me (again: only for me).,
In that case, the tip is redundant (this also removes the double separator from the context menu when right-clicking on the name of a project).By the way, am I correct in assuming the revert of this means that a visible note is preferred over a tool tip?For such important things, yes. Most people don'T wait long enough that the tooltip shows. Also, there are platforms where there is no tooltip. So tooltip should really be a "tip", not to worry about if you don't know it.
Index: src/plugins/compilergcc/compilergcc.cpp
===================================================================
--- src/plugins/compilergcc/compilergcc.cpp (revision 8193)
+++ src/plugins/compilergcc/compilergcc.cpp (working copy)
@@ -563,7 +563,9 @@
else if (data && data->GetKind() == FileTreeData::ftdkProject)
{
// popup menu on a project
- menu->AppendSeparator();
+ wxMenuItem* itm = menu->FindItemByPosition(menu->GetMenuItemCount() - 1);
+ if (itm && !itm->IsSeparator())
+ menu->AppendSeparator();
menu->Append(idMenuCompileFromProjectManager, _("Build"));
menu->Append(idMenuRebuildFromProjectManager, _("Rebuild"));
menu->Append(idMenuCleanFromProjectManager, _("Clean"));
Index: src/plugins/compilergcc/resources/compiler_options.xrc
===================================================================
--- src/plugins/compilergcc/resources/compiler_options.xrc (revision 8193)
+++ src/plugins/compilergcc/resources/compiler_options.xrc (working copy)
@@ -150,7 +159,6 @@
</object>
<object class="sizeritem">
<object class="wxCheckListBox" name="lstCompilerOptions">
- <tooltip>Right-click to setup or edit compiler flags</tooltip>
<style>wxLB_HSCROLL</style>
</object>
<flag>wxTOP|wxLEFT|wxRIGHT|wxEXPAND|wxALIGN_LEFT|wxALIGN_TOP</flag>
Index: src/plugins/compilergcc/resources/compilers/compiler_clang.xml
===================================================================
--- src/plugins/compilergcc/resources/compilers/compiler_clang.xml (revision 8193)
+++ src/plugins/compilergcc/resources/compilers/compiler_clang.xml (working copy)
@@ -7,6 +7,8 @@
<Search envVar="PATH"
for="C"/>
<if platform="windows">
+ <Search path="%ProgramFiles%\LLVM"
+ for="C"/>
<Fallback path="C:\MinGW"/>
</if>
<else>
Why would you do that?Because it will be easier in the longer period of time. You won't have to worry if the options is C or C++.
MSVC for example is one compiler for all.In fact MSVC is MSVC++, I doubt there is any support for C provided by Microsoft, and if I remember correctly, they stated that C11 won't be supported by them.
multy-language/multi-compiler support in a single project.Using different targets and custom build commands we have that already - and I am using it.
I doubt there is any support for C provided by Microsoft,Oh dear... I thought the Windows core was still plain C - it seems it isn't... or they are using another compiler for it.
Here is a patch [...]Giving it a try< leads to tons of errors at startup of C::B, that compiler_options_sort.xml could not be fund. Why? Did I forget to copy / create a file?
Giving it a try< leads to tons of errors at startup of C::B, that compiler_options_sort.xml could not be fund.By the way, has this been resolved?
Strange... are you certain that was the name it warned about? I did add options_common_sort.xml; try running update(.bat) again to see if that fixes it.Oh - I missed hat post. And yes: That was it I figured it out myself when updating from SVN.
Index: src/plugins/compilergcc/compilergcc.cpp
===================================================================
--- src/plugins/compilergcc/compilergcc.cpp (revision 8246)
+++ src/plugins/compilergcc/compilergcc.cpp (working copy)
@@ -2476,7 +2476,7 @@
}
wxString msg;
msg.Printf(_T("\"%s - %s\": The compiler's setup %sis invalid, so Code::Blocks cannot find/run the compiler.\n")
- _T("Probably the toolchain path within the compiler options is not setup correctly?!\n")
+ _T("Probably the toolchain path within the compiler options is not setup correctly?! (Do you have a compiler installed?)\n")
_T("Goto \"Settings->Compiler and debugger...->Global compiler settings->%s->Toolchain executables\"")
_T(" and fix the compiler's setup.\n")
_T("Skipping..."),
Index: src/plugins/compilergcc/resources/compilers/options_gdc.xml
===================================================================
--- src/plugins/compilergcc/resources/compilers/options_gdc.xml (revision 8246)
+++ src/plugins/compilergcc/resources/compilers/options_gdc.xml (working copy)
@@ -81,7 +81,7 @@
<Option name="allow deprecated features"
option="-fdeprecated"/>
<Option name="compile in debug code"
- option="-debug"/>
+ option="-fdebug"/>
<Option name="inline expand functions"
option="-finline-functions"/>
<Option name="compile release version, which means not generating code for contracts and asserts"
Index: src/plugins/compilergcc/resources/compilers/options_common_re.xml
===================================================================
--- src/plugins/compilergcc/resources/compilers/options_common_re.xml (revision 8246)
+++ src/plugins/compilergcc/resources/compilers/options_common_re.xml (working copy)
@@ -203,4 +203,10 @@
msg="1">
<![CDATA[([Ii]nfo:[ \t].*)\(auto-import\)]]>
</RegEx>
+ <RegEx name="Linker warning (different sized sections)"
+ type="warning"
+ msg="2"
+ file="1">
+ <![CDATA[([][{}() \t#%$~[:alnum:]&_:+/\.-]+):[ \t]+(duplicate section.*has different size)]]>
+ </RegEx>
</CodeBlocks_compiler_options>
I had a nightly ready, but during testing on linux I found a showstopper, the 2 latest compiler option/directives are still missing.In share\CodeBlocks\compilers (user, not global), XML files will be saved for any compilers to which flags have been changed/added/removed. It is possible options_gcc.xml was generated during a previous test before the version detection was fixed. These files are loaded preferentially, so either deleting it manually, or resetting the compiler should resolve the problem.
EDIT : can the compiler detection at startup be explained, it made no sense to me.The ones labeled "user defined" mean that they were not detected, but the master path loaded from default.conf is different than that given by auto-detection (this happens either when the user has set their own path, or when auto-detection has changed defaults).
We will ask the user to backup, but then what, do they need to remove something out of it (the compiler section, but for sure not the user sets) ?In my opinion, it should be fine to continue working with the same (unmodified) default.conf (of course, it still should be backed up just in case).
My build is not the newest one (I have 8218), and the two options you have mentioned are there.For me, too - both options are there.
<?xml version="1.0"?>
<!DOCTYPE CodeBlocks_compiler_options>
<CodeBlocks_compiler_options>
<if platform="windows">
<Program name="C" value="mingw32-gcc.exe"/>
<Program name="CPP" value="mingw32-g++.exe"/>
<Program name="LD" value="mingw32-g++.exe"/>
<Program name="DBGconfig" value="gdb_debugger:Default"/>
<Program name="LIB" value="ar.exe"/>
<Program name="WINDRES" value="windres.exe"/>
<Program name="MAKE" value="mingw32-make.exe"/>
</if>
<else>
<Program name="C" value="gcc"/>
<Program name="CPP" value="g++"/>
<Program name="LD" value="g++"/>
<Program name="DBGconfig" value="gdb_debugger:Default"/>
<Program name="LIB" value="ar"/>
<Program name="WINDRES" value=""/>
<Program name="MAKE" value="make"/>
</else>
<Switch name="includeDirs" value="-I"/>
<Switch name="libDirs" value="-L"/>
<Switch name="linkLibs" value="-l"/>
<Switch name="defines" value="-D"/>
<Switch name="genericSwitch" value="-"/>
<Switch name="objectExtension" value="o"/>
<Switch name="needDependencies" value="true"/>
<Switch name="forceCompilerUseQuotes" value="false"/>
<Switch name="forceLinkerUseQuotes" value="false"/>
<Switch name="logging" value="default"/>
<Switch name="libPrefix" value="lib"/>
<Switch name="libExtension" value="a"/>
<Switch name="linkerNeedsLibPrefix" value="false"/>
<Switch name="linkerNeedsLibExtension" value="false"/>
<Switch name="supportsPCH" value="true"/>
<Switch name="PCHExtension" value="h.gch"/>
<Switch name="UseFullSourcePaths" value="true"/>
<!-- Summary of GCC options: http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html -->
<Option name="Produce debugging symbols"
option="-g"
category="Debugging"
checkAgainst="-O -O1 -O2 -O3 -Os"
checkMessage="You have optimizations enabled. This is Not A Good Thing(tm) when producing debugging symbols..."
supersedes="-s"/>
<if platform="windows">
<Option name="Profile code when executed"
option="-pg"
category="Profiling"
additionalLibs="-pg -lgmon"
supersedes="-s"/>
</if>
<else>
<Option name="Profile code when executed"
option="-pg"
category="Profiling"
additionalLibs="-pg"
supersedes="-s"/>
</else>
<!-- warnings -->
<Common name="warnings"/>
<Category name="Warnings">
<Option name="Enable Effective-C++ warnings (thanks Scott Meyers)"
option="-Weffc++"/>
<Option name="Warn whenever a switch statement does not have a default case"
option="-Wswitch-default"/>
<Option name="Warn whenever a switch statement has an index of enumerated type and lacks a case for one or more of the named codes of that enumeration"
option="-Wswitch-enum"/>
<if exec="C -dumpversion"
regex="^[4-9]\.[0-9]"
default="true">
<Option name="Warn if a user supplied include directory does not exist"
option="-Wmissing-include-dirs"/>
</if>
<Option name="Warn if a global function is defined without a previous declaration"
option="-Wmissing-declarations"/>
<Option name="Warn if the compiler detects that code will never be executed"
option="-Wunreachable-code"/>
<Option name="Warn if a function can not be inlined and it was declared as inline"
option="-Winline"/>
<Option name="Warn if floating point values are used in equality comparisons"
option="-Wfloat-equal"/>
<Option name="Warn if an undefined identifier is evaluated in an '#if' directive"
option="-Wundef"/>
<Option name="Warn whenever a pointer is cast such that the required alignment of the target is increased"
option="-Wcast-align"/>
<Option name="Warn if anything is declared more than once in the same scope"
option="-Wredundant-decls"/>
<Option name="Warn about unitialized variables which are initialized with themselves"
option="-Winit-self"/>
<Option name="Warn whenever a local variable shadows another local variable, parameter or global variable or whenever a built-in function is shadowed"
option="-Wshadow"/>
</Category>
<!-- optimization -->
<Common name="optimization"/>
<Option name="Don't keep the frame pointer in a register for functions that don't need one"
option="-fomit-frame-pointer"
category="Optimization"
checkAgainst="-g -ggdb"
checkMessage="You have debugging symbols enabled. This is Not A Good Thing(tm) when optimizing..."/>
<!-- machine dependent options - cpu arch -->
<Common name="architecture"/>
<Command name="CompileObject"
value="$compiler $options $includes -c $file -o $object"/>
<Command name="GenDependencies"
value="$compiler -MM $options -MF $dep_object -MT $object $includes $file"/>
<Command name="CompileResource"
value="$rescomp $res_includes -J rc -O coff -i $file -o $resource_output"/>
<Command name="LinkConsoleExe"
value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs"/>
<if platform="windows">
<Command name="LinkNative"
value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs -Wl,--subsystem,native"/>
<Command name="LinkExe"
value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs -mwindows"/>
<Command name="LinkDynamic"
value="$linker -shared -Wl,--output-def=$def_output -Wl,--out-implib=$static_output -Wl,--dll $libdirs $link_objects $link_resobjects -o $exe_output $link_options $libs"/>
</if>
<else>
<Command name="LinkNative"
value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs"/>
<Command name="LinkExe"
value="$linker $libdirs -o $exe_output $link_objects $link_resobjects $link_options $libs"/>
<Command name="LinkDynamic"
value="$linker -shared $libdirs $link_objects $link_resobjects -o $exe_output $link_options $libs"/>
</else>
<Command name="LinkStatic"
value="$lib_linker -r -s $static_output $link_objects"/>
<Common name="cmds"/>
<Common name="re"/>
<Common name="sort"/>
</CodeBlocks_compiler_options>
<if exec="C -dumpversion"
regex="^4\.[7-9]|^[5-9]\.[0-9]"
default="true">
<Option name="Have g++ follow the C++11 ISO C++ language standard"
option="-std=c++11"
supersedes="-std=c++98 -std=c++0x"/>
<Option name="zero as null pointer constant"
option="-Wzero-as-null-pointer-constant"/>
</if>
killerbot@XIII:~/CodeBlocks/xmlcompiler/xml_compiler/src> gcc -dumpversion
4.6
killerbot@XIII:~/CodeBlocks/xmlcompiler/xml_compiler/src> gcc-4.7 -dumpversion
4.7
killerbot@XIII:~/CodeBlocks/xmlcompiler/xml_compiler/src>
<gcc>
<NAME>
<str>
<![CDATA[GNU GCC Compiler]]>
</str>
</NAME>
<MASTER_PATH>
<str>
<![CDATA[/usr]]>
</str>
</MASTER_PATH>
<C_COMPILER>
<str>
<![CDATA[gcc-4.7]]>
</str>
</C_COMPILER>
<CPP_COMPILER>
<str>
<![CDATA[g++-4.7]]>
</str>
</CPP_COMPILER>
<LINKER>
<str>
<![CDATA[g++-4.7]]>
</str>
</LINKER>
</gcc>
I deleted the "output" folder again, and rerun "update" script, optiotns still don't show up in "options_gcc.xml"The folder ~/.codeblocks/share/codeblocks/compilers is the one you want to clean.
Meaning that either the info in default.conf get's ignored, or do we just have a one time migration problem, and in the latter case can it be avoided ?However, I think you are correct and have found a bug; I will have to double check, but at the point in time when the compiler is executed to retrieve the version number, it *might* not have yet loaded non-default names from the user configuration file. I will look into this.
Index: src/sdk/autodetectcompilers.cpp
===================================================================
--- src/sdk/autodetectcompilers.cpp (revision 8275)
+++ src/sdk/autodetectcompilers.cpp (working copy)
@@ -44,25 +44,12 @@
list->InsertColumn(0, _("Compiler"), wxLIST_FORMAT_LEFT, 380);
list->InsertColumn(1, _("Status"), wxLIST_FORMAT_LEFT, 100);
- bool firstRun = true;
for (size_t i = 0; i < CompilerFactory::GetCompilersCount(); ++i)
{
Compiler* compiler = CompilerFactory::GetCompiler(i);
if (!compiler)
continue;
- if (!compiler->GetMasterPath().IsEmpty())
- {
- firstRun = false; // all master paths are empty on first run
- break;
- }
- }
- for (size_t i = 0; i < CompilerFactory::GetCompilersCount(); ++i)
- {
- Compiler* compiler = CompilerFactory::GetCompiler(i);
- if (!compiler)
- continue;
-
list->InsertItem(list->GetItemCount(), compiler->GetName());
wxString path = compiler->GetMasterPath();
@@ -71,7 +58,7 @@
int idx = list->GetItemCount() - 1;
int highlight = 0;
- if (path.IsEmpty() && !firstRun)
+ if (path.IsEmpty() && Manager::Get()->GetConfigManager(wxT("compiler"))->Exists(wxT("/sets/") + compiler->GetID() + wxT("/name")))
{
// Here, some user-interaction is required not to show this
// dialog again on each new start-up of C::B.
Index: src/sdk/compiler.cpp
===================================================================
--- src/sdk/compiler.cpp (revision 8275)
+++ src/sdk/compiler.cpp (working copy)
@@ -814,6 +814,16 @@
int depth = 0;
wxString categ;
bool exclu = false;
+
+ wxString baseKey = GetParentID().IsEmpty() ? wxT("/sets") : wxT("/user_sets");
+ ConfigManager* cfg = Manager::Get()->GetConfigManager(wxT("compiler"));
+ wxString cmpKey;
+ cmpKey.Printf(wxT("%s/set%3.3d"), baseKey.c_str(), CompilerFactory::GetCompilerIndex(this) + 1);
+ if (!cfg->Exists(cmpKey + wxT("/name")))
+ cmpKey.Printf(wxT("%s/%s"), baseKey.c_str(), m_ID.c_str());
+ if (!cfg->Exists(cmpKey + wxT("/name")))
+ cmpKey.Replace(wxT("-"), wxEmptyString);
+
while (node)
{
const wxString value = node->GetAttribute(wxT("value"), wxEmptyString);
@@ -837,19 +847,19 @@
{
wxString prog = node->GetAttribute(wxT("name"), wxEmptyString);
if (prog == wxT("C"))
- m_Programs.C = value;
+ m_Programs.C = cfg->Read(cmpKey + wxT("/c_compiler"), value);
else if (prog == wxT("CPP"))
- m_Programs.CPP = value;
+ m_Programs.CPP = cfg->Read(cmpKey + wxT("/cpp_compiler"), value);
else if (prog == wxT("LD"))
- m_Programs.LD = value;
+ m_Programs.LD = cfg->Read(cmpKey + wxT("/linker"), value);
else if (prog == wxT("DBGconfig"))
m_Programs.DBGconfig = value;
else if (prog == wxT("LIB"))
- m_Programs.LIB = value;
+ m_Programs.LIB = cfg->Read(cmpKey + wxT("/lib_linker"), value);
else if (prog == wxT("WINDRES"))
- m_Programs.WINDRES = value;
+ m_Programs.WINDRES = cfg->Read(cmpKey + wxT("/res_compiler"), value);
else if (prog == wxT("MAKE"))
- m_Programs.MAKE = value;
+ m_Programs.MAKE = cfg->Read(cmpKey + wxT("/make"), value);
}
else if (node->GetName() == wxT("Switch"))
{
I had a nightly ready, but during testing on linux I found a showstopper, the 2 latest compiler option/directives are still missing.I forgot to ask, has the last patch fixed this on your computer?
They are present in some (did not check all of them) gcc derivatives/ports (like gnu arm), but are missing in the main gcc.
I am talking about :
- std=c++11
- Wzero-as-null-pointer-constant
<gcc>
<NAME>
<str>
<![CDATA[GNU GCC Compiler]]>
</str>
</NAME>
<MASTER_PATH>
<str>
<![CDATA[/usr]]>
</str>
</MASTER_PATH>
<C_COMPILER>
<str>
<![CDATA[gcc-4.7]]>
</str>
</C_COMPILER>
<CPP_COMPILER>
<str>
<![CDATA[g++-4.7]]>
</str>
</CPP_COMPILER>
<LINKER>
<str>
<![CDATA[g++-4.7]]>
</str>
</LINKER>
</gcc>
Personally I think we should fix this first, since this breaks users existing configurations.After four hours of just trying to find the cause of the bug, I would agree, it should be fixed first ;). This bug was far worse than first apparent. It actually deletes all renamed executables on the second launch after the change has been made.
Index: src/sdk/compiler.cpp
===================================================================
--- src/sdk/compiler.cpp (revision 8345)
+++ src/sdk/compiler.cpp (working copy)
@@ -843,23 +843,41 @@
continue;
}
}
- else if (node->GetName() == wxT("Program"))
+ else if (node->GetName() == wxT("Program")) // configuration is read so execution of renamed programs work, m_Mirror is needed to reset names to their defaults before leaving this function
{
wxString prog = node->GetAttribute(wxT("name"), wxEmptyString);
if (prog == wxT("C"))
- m_Programs.C = cfg->Read(cmpKey + wxT("/c_compiler"), value);
+ {
+ m_Programs.C = cfg->Read(cmpKey + wxT("/c_compiler"), value);
+ m_Mirror.Programs.C = value;
+ }
else if (prog == wxT("CPP"))
- m_Programs.CPP = cfg->Read(cmpKey + wxT("/cpp_compiler"), value);
+ {
+ m_Programs.CPP = cfg->Read(cmpKey + wxT("/cpp_compiler"), value);
+ m_Mirror.Programs.CPP = value;
+ }
else if (prog == wxT("LD"))
- m_Programs.LD = cfg->Read(cmpKey + wxT("/linker"), value);
+ {
+ m_Programs.LD = cfg->Read(cmpKey + wxT("/linker"), value);
+ m_Mirror.Programs.LD = value;
+ }
else if (prog == wxT("DBGconfig"))
m_Programs.DBGconfig = value;
else if (prog == wxT("LIB"))
- m_Programs.LIB = cfg->Read(cmpKey + wxT("/lib_linker"), value);
+ {
+ m_Programs.LIB = cfg->Read(cmpKey + wxT("/lib_linker"), value);
+ m_Mirror.Programs.LIB = value;
+ }
else if (prog == wxT("WINDRES"))
+ {
m_Programs.WINDRES = cfg->Read(cmpKey + wxT("/res_compiler"), value);
+ m_Mirror.Programs.WINDRES = value;
+ }
else if (prog == wxT("MAKE"))
- m_Programs.MAKE = cfg->Read(cmpKey + wxT("/make"), value);
+ {
+ m_Programs.MAKE = cfg->Read(cmpKey + wxT("/make"), value);
+ m_Mirror.Programs.MAKE = value;
+ }
}
else if (node->GetName() == wxT("Switch"))
{
@@ -1000,6 +1018,13 @@
}
node = node->GetNext();
}
+ // reset programs to their actual defaults (customized settings are loaded in a different function)
+ m_Programs.C = m_Mirror.Programs.C;
+ m_Programs.CPP = m_Mirror.Programs.CPP;
+ m_Programs.LD = m_Mirror.Programs.LD;
+ m_Programs.LIB = m_Mirror.Programs.LIB;
+ m_Programs.WINDRES = m_Mirror.Programs.WINDRES;
+ m_Programs.MAKE = m_Mirror.Programs.MAKE;
}
void Compiler::LoadRegExArray(const wxString& name, bool globalPrecedence, int recursion)
The following patch fixes it (and has been much more thoroughly tested both on Windows and Linux).... but not thoroughly enough. There is still a small recursion issue that needs to be dealt with.
There is still a small recursion issue that needs to be dealt with.... and dealt with.
Index: src/sdk/compiler.cpp
===================================================================
--- src/sdk/compiler.cpp (revision 8345)
+++ src/sdk/compiler.cpp (working copy)
@@ -843,23 +843,41 @@
continue;
}
}
- else if (node->GetName() == wxT("Program"))
+ else if (node->GetName() == wxT("Program")) // configuration is read so execution of renamed programs work, m_Mirror is needed to reset before leaving this function
{
wxString prog = node->GetAttribute(wxT("name"), wxEmptyString);
if (prog == wxT("C"))
- m_Programs.C = cfg->Read(cmpKey + wxT("/c_compiler"), value);
+ {
+ m_Programs.C = cfg->Read(cmpKey + wxT("/c_compiler"), value);
+ m_Mirror.Programs.C = value;
+ }
else if (prog == wxT("CPP"))
- m_Programs.CPP = cfg->Read(cmpKey + wxT("/cpp_compiler"), value);
+ {
+ m_Programs.CPP = cfg->Read(cmpKey + wxT("/cpp_compiler"), value);
+ m_Mirror.Programs.CPP = value;
+ }
else if (prog == wxT("LD"))
- m_Programs.LD = cfg->Read(cmpKey + wxT("/linker"), value);
+ {
+ m_Programs.LD = cfg->Read(cmpKey + wxT("/linker"), value);
+ m_Mirror.Programs.LD = value;
+ }
else if (prog == wxT("DBGconfig"))
m_Programs.DBGconfig = value;
else if (prog == wxT("LIB"))
- m_Programs.LIB = cfg->Read(cmpKey + wxT("/lib_linker"), value);
+ {
+ m_Programs.LIB = cfg->Read(cmpKey + wxT("/lib_linker"), value);
+ m_Mirror.Programs.LIB = value;
+ }
else if (prog == wxT("WINDRES"))
+ {
m_Programs.WINDRES = cfg->Read(cmpKey + wxT("/res_compiler"), value);
+ m_Mirror.Programs.WINDRES = value;
+ }
else if (prog == wxT("MAKE"))
- m_Programs.MAKE = cfg->Read(cmpKey + wxT("/make"), value);
+ {
+ m_Programs.MAKE = cfg->Read(cmpKey + wxT("/make"), value);
+ m_Mirror.Programs.MAKE = value;
+ }
}
else if (node->GetName() == wxT("Switch"))
{
@@ -1000,6 +1018,15 @@
}
node = node->GetNext();
}
+ if (recursion == 0) // reset programs to their actual defaults (customized settings are loaded in a different function)
+ {
+ m_Programs.C = m_Mirror.Programs.C;
+ m_Programs.CPP = m_Mirror.Programs.CPP;
+ m_Programs.LD = m_Mirror.Programs.LD;
+ m_Programs.LIB = m_Mirror.Programs.LIB;
+ m_Programs.WINDRES = m_Mirror.Programs.WINDRES;
+ m_Programs.MAKE = m_Mirror.Programs.MAKE;
+ }
}
void Compiler::LoadRegExArray(const wxString& name, bool globalPrecedence, int recursion)
Index: src/sdk/autodetectcompilers.cpp
===================================================================
--- src/sdk/autodetectcompilers.cpp (revision 8407)
+++ src/sdk/autodetectcompilers.cpp (working copy)
@@ -96,7 +96,7 @@
else if ( !path.IsEmpty() )
{
// Check, if the master path is valid:
- if ( wxFileName::DirExists(path_no_macros) )
+ if ( wxFileName::DirExists(path_no_macros) && !(path == pathDetected || path_no_macros == pathDetected) )
{
list->SetItem(idx, 1, _("User-defined")); // OK
highlight = 0;
nice belgian beers ;-)From a German point of view: Isn't this a paradoxon? ;D ;D ;D
hmmmm, darn, this weekend for sure, or I owe you some nice belgian beers ;-)Not a problem; I am sure you have been very busy. (Although, if you do not get around to it, that might have to be a rain check; I am currently underage ;).)
One strange things : it claimed the SDCC was user defined. Never touched that one ...That is an artifact of a fix to its auto-detection routine; as it only will report this oddity once (on the switch from trunk to XML compiler), I did not think it was worthwhile to write a special rule for it.
Seems to be ok. I will prepare nightlies.Okay. I will be waiting for the bug reports that only appear after everything is thought to be fixed :).
Index: src/plugins/compilergcc/compileroptionsdlg.cpp
===================================================================
--- src/plugins/compilergcc/compileroptionsdlg.cpp (revision 8435)
+++ src/plugins/compilergcc/compileroptionsdlg.cpp (working copy)
@@ -2777,6 +2777,11 @@
Compiler* compiler = CompilerFactory::GetCompiler(m_CurrentCompilerIdx);
wxTextEntryDialog dlg(this, wxT("List flags that will only be used during C compilation"),
wxT("C - only flags"), compiler->GetCOnlyFlags(), wxTextEntryDialogStyle|wxTE_MULTILINE|wxRESIZE_BORDER);
+ if (dlg.GetSize().GetHeight() < 220)
+ {
+ dlg.SetSize(dlg.GetPosition().x, dlg.GetPosition().y - (220 - dlg.GetSize().GetHeight()) / 2,
+ dlg.GetSize().GetWidth(), 220);
+ }
dlg.ShowModal();
wxString flags = dlg.GetValue();
flags.Replace(wxT("\n"), wxT(" "));
@@ -2795,6 +2800,11 @@
Compiler* compiler = CompilerFactory::GetCompiler(m_CurrentCompilerIdx);
wxTextEntryDialog dlg(this, wxT("List flags that will only be used during C++ compilation"),
wxT("C++ - only flags"), compiler->GetCPPOnlyFlags(), wxTextEntryDialogStyle|wxTE_MULTILINE|wxRESIZE_BORDER);
+ if (dlg.GetSize().GetHeight() < 220)
+ {
+ dlg.SetSize(dlg.GetPosition().x, dlg.GetPosition().y - (220 - dlg.GetSize().GetHeight()) / 2,
+ dlg.GetSize().GetWidth(), 220);
+ }
dlg.ShowModal();
wxString flags = dlg.GetValue();
flags.Replace(wxT("\n"), wxT(" "));
Index: src/plugins/compilergcc/resources/compilers/options_common_warnings.xml
===================================================================
--- src/plugins/compilergcc/resources/compilers/options_common_warnings.xml (revision 8435)
+++ src/plugins/compilergcc/resources/compilers/options_common_warnings.xml (working copy)
@@ -26,7 +26,7 @@
<Option name="Have g++ follow the C++11 ISO C++ language standard"
option="-std=c++11"
supersedes="-std=c++98 -std=c++0x"/>
- <Option name="zero as null pointer constant"
+ <Option name="Warn if '0' is used as a null pointer constant"
option="-Wzero-as-null-pointer-constant"/>
</if>
<Option name="Enable warnings demanded by strict ISO C and ISO C++"
Is it something that can happen often, or only in a very rare case ? If it is rather rare then indeed the hack might not be worth the hassle.The hack is already in svn...
The hack is already in svn......the description now, too.
What do you think ?Why not? I though in this case, as both hacks are directly after each other it would not be needed. Because if you see the one hack you'll also see the other.
good idea to file it to ubuntuBug reported (https://bugs.launchpad.net/ubuntu/+bug/1064082).
Wouldn't the wxWidgets bug-tracker be the right place to report?!good idea to file it to ubuntuBug reported (https://bugs.launchpad.net/ubuntu/+bug/1064082).
Wouldn't the wxWidgets bug-tracker be the right place to report?!I actually was not quite sure where it belonged. I will submit it there as well. (It appears that this was reported (http://trac.wxwidgets.org/ticket/1626) a while ago as well.)
Index: src/plugins/compilergcc/compilergcc.cpp
===================================================================
--- src/plugins/compilergcc/compilergcc.cpp (revision 8554)
+++ src/plugins/compilergcc/compilergcc.cpp (working copy)
@@ -3728,8 +3728,9 @@
wxString CompilerGCC::GetErrWarnStr()
{
- return wxString::Format(_("%u error(s), %u warning(s)"),
- m_Errors.GetCount(cltError), m_Errors.GetCount(cltWarning));
+ return wxString::Format(_("%u %s, %u %s"),
+ m_Errors.GetCount(cltError), wxString(m_Errors.GetCount(cltError) == 1 ? _("error") : _("errors")).wx_str(),
+ m_Errors.GetCount(cltWarning), wxString(m_Errors.GetCount(cltWarning) == 1 ? _("warning") : _("warnings")).wx_str());
}
wxString CompilerGCC::GetMinSecStr()
@@ -3737,6 +3738,7 @@
long int elapsed = (wxGetLocalTimeMillis() - m_StartTime).ToLong() / 1000;
int mins = elapsed / 60;
int secs = (elapsed % 60);
- return wxString::Format(_("%d minute(s), %d second(s)"), mins, secs);
-;
+ return wxString::Format(_("%d %s, %d %s"),
+ mins, wxString(mins == 1 ? _("minute") : _("minutes")).wx_str(),
+ secs, wxString(secs == 1 ? _("second") : _("seconds")).wx_str());
}
Index: src/plugins/compilergcc/directcommands.cpp
===================================================================
--- src/plugins/compilergcc/directcommands.cpp (revision 8554)
+++ src/plugins/compilergcc/directcommands.cpp (working copy)
@@ -613,8 +613,8 @@
if (!fileMissing.IsEmpty())
{
wxString warn;
- warn.Printf(_("WARNING: Target '%s': Unable to resolve %lu external dependenc%s:"),
- target->GetFullTitle().wx_str(), static_cast<unsigned long>(fileMissing.Count()), wxString(fileMissing.Count() == 1 ? _("y") : _("ies")).wx_str());
+ warn.Printf(_("WARNING: Target '%s': Unable to resolve %lu external %s:"),
+ target->GetFullTitle().wx_str(), static_cast<unsigned long>(fileMissing.Count()), wxString(fileMissing.Count() == 1 ? _("dependency") : _("dependencies")).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]);
I see no problem with the current version ... KISS for the win.I agree. Either we do it like that in all places or we just keep it simple. It has some more advantages: You don't have to translate many units. Already now we have several thousands of units to translate anyways - adding even more might not be the best thing to do you know... ;)
@Alpha: If you want to, make a poEdit session on Code::Blocks. Then you know what I am talking about... ;DI can imagine :o (and I have enough trouble as it is when I need to translate just a few sentences).
Do not worry, I am not trying to argue you change your mind ;). In my reading, I had bumped into the following, and thought I would post some links in case the topic of plural translations was ever revisited in the future.I know about these, but they all cause to double the units to translate in the worst case. The question is: In an IDE - is "dependency/ies" enough, or do you really want to be that super correct. I mean its not a scientific thesis we are doing here. And (most important to me) we don't want to scare away translators.
- wxPLURAL() (http://docs.wxwidgets.org/trunk/group__group__funcmacro__string.html#gadc7c2f1bab3914af93feb47945003409)
- wxTranslations::GetString() (http://docs.wxwidgets.org/trunk/classwx_translations.html#a7480771c24a53e0ccf1170a3a70b2ba4)
- gettext - plural forms (http://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Plural-forms.html)
- gettext - translating plural forms (http://www.gnu.org/savannah-checkouts/gnu/gettext/manual/html_node/Translating-plural-forms.html)
I have some changes in my local copy; would you prefer to have them now (some changes are not yet thoroughly tested), or after the merge (assuming it will be soon)?After.
Morten: Can you show us if you can do a pain free svn merge?Sorry, no time atm, but I'll see what I can do later this or next week.
Sorry, no time atm, but I'll see what I can do later this or next week.Done. Branch is successfully merged into trunk now (with only ~10 serious conflicts only, btw. - easy to resolve with the conflict manager of my SVN tool suite ;-)).
It seems that if there are compile errors and you hit f8, the debugger is not stopped, but continues, no dialog, no nothing.Is that related to the compiler?
p.s. this doesn't happen on a simple project :(
Any explanation why SDCC compiler is detected as user defined, but I've never change anything in it?Windows or Linux?
Happened both at work and at home.
Is that related to the compiler?I suppose it is. It happens when there are some major header changes and there are more that one compilation commands.
Windows or Linux?Both linux.
I'll try to reproduce this with the C::B's project.That would be nice because I don't understand currently, how a compiler session could interfere with a debugger session?!
That would be nice because I don't understand currently, how a compiler session could interfere with a debugger session?!This is if you have the option "Auto-build project if it is not up-to-date" enabled.
This is if you have the option "Auto-build project if it is not up-to-date" enabled.done that, started debugging and it stops at the build error, shows the asks if I want to to debug anyways and both options work for me...?!
I suppose it is. It happens when there are some major header changes?
Is there a safe way to reproduce?Yes, at least on linux.
Any explanation why SDCC compiler is detected as user defined, but I've never change anything in it?Previously, the default master path for SDCC was incorrectly
What I'm asking for is to make "o" the default for SDCC object files because "rel" has been totally irrelevant for months.Done in trunk. I guess nobody of us works with that compiler, so hopefully no other users complain that might still use the version that requires "rel"... we will see...
A question about SDCC: why has objectExtension been changed from "rel" to "o"? This doesn't work for me,Uh-oh...
I have now updated my Keil C51 and IAR ICC8051 compiler plugin patch to the new XML compiler framework. It can be found here:Great. In a quick peek, however, it appears that the baycom.org upload missed the files compilerIAR.cpp, compilerKeilC51.cpp, compilerIAR.h, and compilerKeilC51.h.
http://www.baycom.org/~tom/cb/keiliarcompilers.patch
(It is also at Berlios Patch #3152, but Berlios seems to eat new files from uploaded patches, so the Berlios version is incomplete).
I'm not so convinced about the compiler XML files. It seems I cannot use them both for Keil and IAR.Yes, these auto-detection routines are very basic; only the simpler compilers can make use of them currently. However, if you happen to have any ideas or suggestions for a better file format, I would appreciate hearing them.
A question about SDCC: why has objectExtension been changed from "rel" to "o"? This doesn't work for me,Uh-oh...
Do any SDCC users have a version number where this changed?
Great. In a quick peek, however, it appears that the baycom.org upload missed the files compilerIAR.cpp, compilerKeilC51.cpp, compilerIAR.h, and compilerKeilC51.h.
wxRegKey key; // defaults to HKCR
key.SetName(wxT("HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\Keil \265Vision3"));
if (key.Exists() && key.Open(wxRegKey::Read)) // found; read it
key.QueryValue(wxT("LastInstallDir"), m_MasterPath);
key.SetName(wxT("HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\Keil\\265Vision3"));
<if platform="windows">
<Program name="LD" value="LX51.exe"/>
<Program name="LIB" value="LIBX51.exe"/>
</if>
<else>
<Program name="LD" value="LX51"/>
<Program name="LIB" value="LIBX51"/>
</else>
<if platform="windows">
<Program name="CPP" value="CX51.exe"/>
<Program name="LD" value="LX51.exe"/>
<Program name="LIB" value="LIBX51.exe"/>
</if>
<else>
<Program name="CPP" value="CX51"/>
<Program name="LD" value="LX51"/>
<Program name="LIB" value="LIBX51"/>
</else>
I don't think it ever has changed or become irrelevant. The SDCC manualAccording to PM with user squalyl, PIC port produces *.o because it uses gpasm and gplink. The easier solution would be to duplicate SDCC to create SDCC-PIC, however, I would prefer to instead detect the correct option. Do you have a list of the specific flags that switch it to PIC (is it -mpic14 and -mpic16)? (I plan to revert the default to *.rel.)
http://sdcc.sourceforge.net/doc/sdccman.pdf states on p.24 that the object file extension is .rel.
Looking at the sourceforge SVN source code of SDCC, it's slightly more complicated. AVR, DS390, HC08, MCS51, XA51 and Z80 ports use .rel as object extension, only the PIC14 and PIC16 backends use .o as object extension (see sdcc/src/*/main.c, the PORT structs). I'd consider the PIC backends as of the lesser stable/mature backends - so it seems strange to break the stable backends because of a few unstable ones...
So it seems the correct fix would be (apart from convincing SDCC developers to use the same extension for all backends) to select the object file extension based on which architecture switch was selected...
did you mean:Codekey.SetName(wxT("HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\Keil\\265Vision3"));
Here (options_keilcx51.xml):Codedid you intend to have:<if platform="windows">
<Program name="LD" value="LX51.exe"/>
<Program name="LIB" value="LIBX51.exe"/>
</if>
<else>
<Program name="LD" value="LX51"/>
<Program name="LIB" value="LIBX51"/>
</else>Code<if platform="windows">
<Program name="CPP" value="CX51.exe"/>
<Program name="LD" value="LX51.exe"/>
<Program name="LIB" value="LIBX51.exe"/>
</if>
<else>
<Program name="CPP" value="CX51"/>
<Program name="LD" value="LX51"/>
<Program name="LIB" value="LIBX51"/>
</else>
Attached is a modified version of your patch. There are some changes to formatting, removal of sections that appeared to have no purpose, and tweaks/fixes. Could you please test and let me know if it still works as intended?I will do that, but it will most likely be after new year.
Do you have a list of the specific flags that switch it to PIC (is it -mpic14 and -mpic16)? (I plan to revert the default to *.rel.)Yes, exactly.
Um, no, I meant the lowercase greek letter mu, µ. So the directory component should be "Keil µVision3" (µVision being the name of their IDE)Ah, okay.
I will do that, but it will most likely be after new year.Sure; when you do, use the version attached here (it formats a little more, and reverts my change to mu).
Sure; when you do, use the version attached here (it formats a little more, and reverts my change to mu).
The only thing I forgot: DBGconfig should be set to the empty string in options_keilc51.xml and options_iar8051.xml; axs_debugger is not yet merged.Okay.
Index: src/plugins/compilergcc/compilerXML.cpp
===================================================================
--- src/plugins/compilergcc/compilerXML.cpp (revision 9423)
+++ src/plugins/compilergcc/compilerXML.cpp (working copy)
@@ -15,7 +15,7 @@
#include "compilerXML.h"
CompilerXML::CompilerXML(const wxString& name, const wxString& ID, const wxString& file)
- : Compiler(name, ID), m_fileName(file)
+ : Compiler(_(name), ID), m_fileName(file)
{
wxXmlDocument compiler;
compiler.Load(m_fileName);
||=== Build: Compiler in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler) ===|
C:\Users\Gerard_2\Documents\CodeBlocks_SVN\CodeBlocks_src\src\plugins\compilergcc\compilerXML.cpp||In constructor 'CompilerXML::CompilerXML(const wxString&, const wxString&, const wxString&)':|
C:\wxWidgets-2.8.12\include\wx\wxchar.h|235|error: 'Lname' was not declared in this scope|
C:\wxWidgets-2.8.12\include\wx\cpp.h|17|note: in definition of macro 'wxCONCAT_HELPER'|
C:\wxWidgets-2.8.12\include\wx\intl.h|48|note: in expansion of macro 'wxT'|
C:\Users\Gerard_2\Documents\CodeBlocks_SVN\CodeBlocks_src\src\plugins\compilergcc\compilerXML.cpp|18|note: in expansion of macro '_'|
||=== Build failed: 1 error(s), 0 warning(s) (0 minute(s), 4 second(s)) ===|
233 #if wxUSE_UNICODE
234 /* use wxCONCAT_HELPER so that x could be expanded if it's a macro */
235 #define wxT(x) wxCONCAT_HELPER(L, x)
236 #else /* !Unicode */
237 #define wxT(x) x
238 #endif /* Unicode/!Unicode */
I tried your patch but I obtain a compilation error :Quote...
C:\wxWidgets-2.8.12\include\wx\wxchar.h|235|error: 'Lname' was not declared in this scope|
...
do you really want to translate compiler names like 'GCC' ?No, I don't.
I tried your patch but I obtain a compilation error : [...]I wonder why it worked for me then...
Index: src/plugins/compilergcc/compilerXML.cpp
===================================================================
--- src/plugins/compilergcc/compilerXML.cpp (revision 9423)
+++ src/plugins/compilergcc/compilerXML.cpp (working copy)
@@ -15,7 +15,7 @@
#include "compilerXML.h"
CompilerXML::CompilerXML(const wxString& name, const wxString& ID, const wxString& file)
- : Compiler(name, ID), m_fileName(file)
+ : Compiler(wxGetTranslation(name), ID), m_fileName(file)
{
wxXmlDocument compiler;
compiler.Load(m_fileName);
Index: src/sdk/compiler.cpp
===================================================================
--- src/sdk/compiler.cpp (revision 9423)
+++ src/sdk/compiler.cpp (working copy)
@@ -963,12 +963,12 @@
wxString exclusive;
if (!node->GetAttribute(wxT("exclusive"), &exclusive))
exclusive = (exclu ? wxT("true") : wxT("false"));
- m_Options.AddOption(node->GetAttribute(wxT("name"), wxEmptyString),
+ m_Options.AddOption(wxGetTranslation(node->GetAttribute(wxT("name"), wxEmptyString)),
node->GetAttribute(wxT("option"), wxEmptyString),
- category,
+ wxGetTranslation(category),
node->GetAttribute(wxT("additionalLibs"), wxEmptyString),
node->GetAttribute(wxT("checkAgainst"), wxEmptyString),
- node->GetAttribute(wxT("checkMessage"), wxEmptyString),
+ wxGetTranslation(node->GetAttribute(wxT("checkMessage"), wxEmptyString)),
node->GetAttribute(wxT("supersedes"), wxEmptyString),
exclusive == wxT("true"));
}
@@ -1121,7 +1121,7 @@
else if (tp == wxT("info"))
clt = cltInfo;
wxArrayString msg = GetArrayFromString(node->GetAttribute(wxT("msg"), wxEmptyString) + wxT(";0;0"));
- m_RegExes.Add(RegExStruct(node->GetAttribute(wxT("name"), wxEmptyString), clt,
+ m_RegExes.Add(RegExStruct(wxGetTranslation(node->GetAttribute(wxT("name"), wxEmptyString)), clt,
node->GetNodeContent().Trim().Trim(false), wxAtoi(msg[0]),
wxAtoi(node->GetAttribute(wxT("file"), wxT("0"))),
wxAtoi(node->GetAttribute(wxT("line"), wxT("0"))),
With this last patch, it works ;) (at least on the string I mentioned in my previous post).Okay, I will commit soon, if no further problems are identified.
Now, my job is : extract all "name" strings from .xml file and add them in my .po file.Maybe a script could extract the strings? It would likely be easier in the long run, for when the .xml files are updated.
Maybe a script could extract the strings?It's exactly what I do. I have updated my extracting tool and testing it.
echo ""
echo "************************************************"
echo "* extracting strings from .xml compilers files *"
echo "************************************************"
echo ""
find ../plugins/compilergcc/resources/compilers | grep -F .xml | xargs grep -F "CodeBlocks_compiler name" > src_xml.cpp 2>> log.txt
find ../plugins/compilergcc/resources/compilers | grep -F .xml | xargs grep -F "Option name" >> src_xml.cpp 2>> log.txt
find ../plugins/compilergcc/resources/compilers | grep -F .xml | xargs grep -F "checkMessage" >> src_xml.cpp 2>> log.txt
grep -v mabi src_xml.cpp | grep -v mno | grep -v apcs | grep -v mtpcs | grep -v mshed | grep -v msoft | grep -v mhard | grep -v mfpe | grep -v msched | grep -v mlong | grep -v mpic | grep -v mcirrus | grep -v mcalle | grep -v mpoke | grep -v mwords > src_xml2.cpp
xgettext -a -o xml.pot src_xml2.cpp
find xml.pot >> files.txt
An afterthought:
Looking back on this, I think I made a major design failure. Moving default settings and flags to .xml I still believe was a good choice, however, as soon as I started trying to do things like <if platform="windows"> ... </if>, it became a hack on the purpose of XML. Logic does not belong at all in a data file. This should have been either left in code, or (better) migrated to a script.
I guess this is another item to add to my todo list, and a lesson on planning ahead :-\ .
Sorry to post on this old thread. I acknowledged any CodeBlocks developers' works but I have to say your XML based compiler really caused me to suffer for almost a whole day. I don't want to be rude but I had to say you did make a completely design failure and I do not think XML was a good choice for anything. Sorry.+1 here. Squirrel would have been the better choice for defining compiler configurations, but now it is already too late.
+1 here. Squirrel would have been the better choice for defining compiler configurations, but now it is already too late.Thank you but I'm only a high school teacher and I don't have the skills needed to do professional coding. I'm not originally teach programming either but because the school's shortage of teacher I attended a short course and started to teach programming alongside with my own elementary algebra. I only know an outdated subset of C++98 and so do my students but recently some of the curious ones started playing with C++11. I can't help with this, sorry.
If you want to design the same system based on squirrel scripts I could help you with the review and guidance :)