-------------- Build: default in Lethal_Sp4ce_irr (compiler: GNU GCC Compiler)---------------
mingw32-g++.exe -std=c++11 -IC:\SDL-1.2.15\include\SDL -IC:\irrlicht-1.8\include -IC:\SDL_mixer-1.2.12 -c D:\git\lethal_sp4ce_master\build\Lethal_Sp4ce_irr\src\ls_audio.cpp -o .objs\src\ls_audio.o
cc1plus.exe: error: unrecognized command line option "-std=c++11"
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings (0 minutes, 0 seconds)
This is the problem: http://wiki.codeblocks.org/index.php?title=FAQ-General#Q:_What_Code::Blocks_is_not.3FYes CB is not a compiler, however DevC++ also uses Mingw32-gcc as the compiler and as I said before the project compiles fine using DevC++ as the IDE.
It should go (automatically) into "Compiler flags".
It should go (automatically) into "Compiler flags".
Is there a bug here that needs solving? Or is this just a configuration problem?
Is there a bug here that needs solving? Or is this just a configuration problem?
It should go (automatically) into "Compiler flags".Are you sure? IMHO the philosophy is/was as follows:
It should go (automatically) into "Compiler flags".Are you sure? IMHO the philosophy is/was as follows:
If a user provided a compiler flag that is present in the checkable list of compiler switches to "other options", then we are in trouble: Checkable list defines the switch as "off", other options as "on". In that case the checkable compiler switches over-rule the other options.
So to make it simple: Never put options that are available in the checkable list of compiler switches (the check-boxes) into other options. This is by design.
If CB silently removes '-Wall' from 'other options' and does not turn on the checkable switch at the same time, it's definitely a bug by design!No problem: At runtime, when you load a project file its managed correctly as the options are being sorted into the appropriate settings. So, if we decide to change an option (i.e. move it to "default") its no problem after you updated C::B and re-opening the project file.
What if '-fexceptions' becomes a checkable switch some day?
No problem: At runtime, when you load a project file its managed correctly as the options are being sorted into the appropriate settings. So, if we decide to change an option (i.e. move it to "default") its no problem after you updated C::B and re-opening the project file.With the current (magic) implementation, I'm not sure what will happen ;)
In a single run, however, there is no way to find out what you mean when you tell the compiler on one setting page to enable and on the other to disable an option.It's easy to find out what I mean by '-Wall' ... I want to see the string '-Wall' in the compiler's command line, nothing else. If CB removes the option from 'other options', I don't have explicitly turned off the checkable switch, it's off by default.
... What ever magic we do here is wrong in 50% of the cases. How would you decide in such a case?The best decision would be: do no magic at all if you can't be sure that it's ok to do so, serious.
If you want to provide the feature of "automatically convert 'other options' to switches", ask the user beforehand. But never do it silently. As you said: your magic will be wrong in 50% of the cases. In My case likely to 100% ;DHm, post the exact steps to show your problem.
If you want to provide the feature of "automatically convert 'other options' to switches", ask the user beforehand. But never do it silently. As you said: your magic will be wrong in 50% of the cases. In My case likely to 100% ;DHm, post the exact steps to show your problem.
As far as I know and seen this in action: If you type -Wall in other options and the compiler has a switch for -Wall, -Wall will be removed from other options and the switch will be enabled. This means that the command used for compilation won't change.
Do you see something else?
Index: src/plugins/compilergcc/compileroptionsdlg.cpp
===================================================================
--- src/plugins/compilergcc/compileroptionsdlg.cpp (revision 9000)
+++ src/plugins/compilergcc/compileroptionsdlg.cpp (working copy)
@@ -912,17 +971,6 @@
m_LinkerOptions.Insert(copt->additionalLibs, 0);
}
}
- else
- {
- // for disabled options, remove relative text option *and*
- // relative linker option
- int idx = m_CompilerOptions.Index(copt->option);
- if (idx != wxNOT_FOUND)
- m_CompilerOptions.RemoveAt(idx, 1);
- idx = m_LinkerOptions.Index(copt->additionalLibs);
- if (idx != wxNOT_FOUND)
- m_LinkerOptions.RemoveAt(idx, 1);
- }
}
// linker options and libs
Yes, using 12.11 on Windows it just removes the project other option; it does NOT set "-Wall" in the compiler options.Yes, of course not - for me this is expected behaviour.
And we do no magi here at all - we just decided that the checkable list over-rules "other options". It has been like that since the beginning and only a very few people complained. Most were happy when we told how it is working behind the scenes. So I still don't see any need for change here, sorry.Sorry to say it, but this is a magic and it is a bit unexpected.
I guess users (including me) think that the list compiler flags and other options are combined together using and/sum operation.Yes - and thats how its done - using AND. "on" AND "off" equals "off". Thats how it is - no magic. 8)
Is there a technical reason behind this behaviour or this is just a decision?You have to make a decision here.
I'm afraid osdt still fails to see the full picture:I have a different case here. First of all I didn't know there was a flag for '-std=c++11' in 'compiler flags'. What I did was to read gcc documentation, decide that I need a '-std=c++11' option and add it to 'other options'. So I DIDN'T tell cb to disable '-std=c++11' in the 'compiler flags' and enable it in 'other options', it's just the consequence of cb's design. And most of the novice will just copy the required options from a website or somewhere else and paste them into the 'other compiler options' without knowing about the flags. And then what? In case they see some options are missing from the command string, maybe they will fill this as a bug, which actually isn't.
if you hit OK and "-Wall" in the checkable list is off, but you have -Wall in "other options" defined to be "on", then you tell C::B on the one hand "do not use -Wall" and on the other hand "do use -Wall".
Yes - and thats how its done - using AND. "on" AND "off" equals "off". Thats how it is - no magic. 8)My mistake here -> I though about OR.
For example scarphin's case of a flag used in old C::B and in the new C::B version it is added to the list of flags? Would this still work?What happens is: If you open a project all compiler flags are being parsed (they are a list of flags). If found in the "checkbox based" settings the checkbox is enabled and if a flag is not in that list its being put to "other options". So, what happens in this specific case of a compiler option being made "official" is that this flag is being applied in the UI, but its now in a different place - in the checklist box.
I'm afraid osdt still fails to see the full picture:I don't think so. But I get your point: "checkable compiler switches over-rule the other options" generally!
if you hit OK and "-Wall" in the checkable list is off, but you have -Wall in "other options" defined to be "on", then you tell C::B on the one hand "do not use -Wall" and on the other hand "do use -Wall".
And we do no magi here at all - we just decided that the checkable list over-rules "other options". It has been like that since the beginning and only a very few people complained. Most were happy when we told how it is working behind the scenes. So I still don't see any need for change here, sorry.
I have a different case here. First of all I didn't know there was a flag for '-std=c++11' in 'compiler flags'. What I did was to read gcc documentation, decide that I need a '-std=c++11' option and add it to 'other options'. So I DIDN'T tell cb to disable '-std=c++11' in the 'compiler flags ...
As I've stated earlier: If '-fexceptions' becomes a switch some day, CB will silently remove it from 'other options' the first time the user modfies the project's build-options.That is plain wrong, as I mentioned already. Nothing will get lost it will work as expected.
You are right, my apologies for that!If '-fexceptions' becomes a switch some day, CB will silently remove it from 'other options' the first time the user modfies the project's build-options.That is plain wrong, as I mentioned already. Nothing will get lost it will work as expected.
I think the only feasible way of handling this would be that in case we realise a difference between the checklist based and the other options we issue a warning asking what to do.Just display a warning "-Wall has been removed\nUse the checklist instead".
The issue here is that you can use scripting (?) but at least macros in "other options" - so its not so easy to implement! And there is no automatism that will work reliable.Scripts and macros are not recognized by the current implementation. It compares each line with avaiable switches. ('$WALL' and '-Wall -Wextra' works as expected ;) )
Index: src/plugins/compilergcc/compileroptionsdlg.cpp
===================================================================
--- src/plugins/compilergcc/compileroptionsdlg.cpp (revision 9000)
+++ src/plugins/compilergcc/compileroptionsdlg.cpp (working copy)
@@ -900,6 +900,8 @@
}
}
+ wxArrayString compilerOpConflicts;
+ wxArrayString linkerOpConflicts;
for (unsigned int i = 0; i < m_Options.GetCount(); ++i)
{
CompOption* copt = m_Options.GetOption(i);
@@ -916,15 +918,32 @@
{
// for disabled options, remove relative text option *and*
// relative linker option
- int idx = m_CompilerOptions.Index(copt->option);
- if (idx != wxNOT_FOUND)
- m_CompilerOptions.RemoveAt(idx, 1);
- idx = m_LinkerOptions.Index(copt->additionalLibs);
- if (idx != wxNOT_FOUND)
- m_LinkerOptions.RemoveAt(idx, 1);
+ if (m_CompilerOptions.Index(copt->option) != wxNOT_FOUND)
+ compilerOpConflicts.Add(copt->option);
+ if (m_LinkerOptions.Index(copt->additionalLibs) != wxNOT_FOUND)
+ linkerOpConflicts.Add(copt->additionalLibs);
}
}
+ if (!compilerOpConflicts.IsEmpty() || !linkerOpConflicts.IsEmpty())
+ {
+ wxString msg = _("The compiler flags\n ")
+ + GetStringFromArray(compilerOpConflicts, wxT("\n "))
+ + GetStringFromArray(linkerOpConflicts, wxT("\n "));
+ msg.RemoveLast(2); // remove two trailing spaces
+ msg += _("were stated in 'Other Options' but unchecked in 'Compiler Flags'.\n"
+ "Do you want to enable these flags?");
+ AnnoyingDialog dlg(_("Enable compiler flags?"), msg,
+ AnnoyingDialog::YES_NO, wxID_NO);
+ if (dlg.ShowModal() == wxID_NO)
+ {
+ for (size_t i = 0; i < compilerOpConflicts.GetCount(); ++i)
+ m_CompilerOptions.Remove(compilerOpConflicts[i]);
+ for (size_t i = 0; i < linkerOpConflicts.GetCount(); ++i)
+ m_LinkerOptions.Remove(linkerOpConflicts[i]);
+ }
+ }
+
// linker options and libs
wxListBox* lstLibs = XRCCTRL(*this, "lstLibs", wxListBox);
for (int i = 0; i < (int)lstLibs->GetCount(); ++i)
Free untested annoying dialog:Compiler error:
/share/source/c/osdt/codeblocks/master/src/plugins/compilergcc/compileroptionsdlg.cpp|937|error: no matching function for call to 'AnnoyingDialog::AnnoyingDialog(const wxChar*, wxString&, AnnoyingDialog::dStyle, <anonymous enum>)'
Index: src/plugins/compilergcc/compileroptionsdlg.cpp
===================================================================
--- src/plugins/compilergcc/compileroptionsdlg.cpp (revision 9000)
+++ src/plugins/compilergcc/compileroptionsdlg.cpp (working copy)
@@ -900,6 +900,8 @@
}
}
+ wxArrayString compilerOpConflicts;
+ wxArrayString linkerOpConflicts;
for (unsigned int i = 0; i < m_Options.GetCount(); ++i)
{
CompOption* copt = m_Options.GetOption(i);
@@ -916,15 +918,32 @@
{
// for disabled options, remove relative text option *and*
// relative linker option
- int idx = m_CompilerOptions.Index(copt->option);
- if (idx != wxNOT_FOUND)
- m_CompilerOptions.RemoveAt(idx, 1);
- idx = m_LinkerOptions.Index(copt->additionalLibs);
- if (idx != wxNOT_FOUND)
- m_LinkerOptions.RemoveAt(idx, 1);
+ if (m_CompilerOptions.Index(copt->option) != wxNOT_FOUND)
+ compilerOpConflicts.Add(copt->option);
+ if (m_LinkerOptions.Index(copt->additionalLibs) != wxNOT_FOUND)
+ linkerOpConflicts.Add(copt->additionalLibs);
}
}
+ if (!compilerOpConflicts.IsEmpty() || !linkerOpConflicts.IsEmpty())
+ {
+ wxString msg = _("The compiler flags\n ")
+ + GetStringFromArray(compilerOpConflicts, wxT("\n "))
+ + GetStringFromArray(linkerOpConflicts, wxT("\n "));
+ msg.RemoveLast(2); // remove two trailing spaces
+ msg += _("were stated in 'Other Options' but unchecked in 'Compiler Flags'.\n"
+ "Do you want to enable these flags?");
+ AnnoyingDialog dlg(_("Enable compiler flags?"), msg, wxART_INFORMATION,
+ AnnoyingDialog::YES_NO, wxID_NO);
+ if (dlg.ShowModal() == wxID_NO)
+ {
+ for (size_t i = 0; i < compilerOpConflicts.GetCount(); ++i)
+ m_CompilerOptions.Remove(compilerOpConflicts[i]);
+ for (size_t i = 0; i < linkerOpConflicts.GetCount(); ++i)
+ m_LinkerOptions.Remove(linkerOpConflicts[i]);
+ }
+ }
+
// linker options and libs
wxListBox* lstLibs = XRCCTRL(*this, "lstLibs", wxListBox);
for (int i = 0; i < (int)lstLibs->GetCount(); ++i)
I'll vote for wxID_YES instead of wxID_NO ;)It will be wxID_NO for the time being so that previous default behaviour remains consistent. (However, this could change soon (http://forums.codeblocks.org/index.php/topic,17873.0.html).)