-std=c++11 not working (CB12.11)

[osdt]

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%

- osdt

[oBFusCATed]

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%

Hm, 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?

[stahta01]

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%

Hm, 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?

Yes, using 12.11 on Windows it just removes the project other option; it does NOT set "-Wall" in the compiler options.

Tim S.

[Alpha]

Untested:

Code

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

However, what is the expected behaviour?

[MortenMacFly]

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.

I'm afraid osdt still fails to see the full picture:
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.

[oBFusCATed]

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.
Is there a technical reason behind this behaviour or this is just a decision?

[MortenMacFly]

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.

Is there a technical reason behind this behaviour or this is just a decision?

You have to make a decision here.

[scarphin]

I'm afraid osdt still fails to see the full picture:
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".

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.

Also there is the other case. Suppose one has defined some compiler option in 'other options'. Then cb gets updated and a compiler flag is added for that very option defined in 'other options'. What will be the behavior of cb in that case?

I think both settings (compiler flags and other options) must be mixed in the resulting command or 'other options' must be automatically added to 'compiler flags' if available.

[oBFusCATed]

Yes - and thats how its done - using AND. "on" AND "off" equals "off". Thats how it is - no magic.

My mistake here -> I though about OR.

Could we change it? What would be the downsides, because there are plenty of examples where this decision will break things.
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?

[MortenMacFly]

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.

So nothing gets lost, its just being visualised differently.

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. 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.

But if you decide to go for such a dialog - make it an annoying dialog. Because still: The overall goal is to use the checklist based list of compiler options in the first place and in case you don't find there what you are looking for use "other options" as a last resort.

If people just "copy and paste" from the internet w/o trying to understand what they are doing I don't know if its helpful to them if we account for such laziness. Its a very bad thing to do in the end.

[osdt]

I'm afraid osdt still fails to see the full picture:
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 don't think so. But I get your point: "checkable compiler switches over-rule the other options" generally!
You forget completly that the user don't have switched some option off, its off by default. So it's not the user's intention to switch it off, right? Nobody will turn '-Wall' off explicitly and then add '-Wall' to 'other options'. Would make no sense, right?

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 ...

@MortenMacFly: What was the intention by adding '-std=c++11' to 'other options'? Think about it, please!

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.

- osdt

[MortenMacFly]

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.

[osdt]

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!

I was of the opinion that 'Other options' are stored separately and then handled exactly as in the GUI (remove -fexceptions without to turn the switch on). But thats clearly not the case.

- osdt

[osdt]

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 )

- osdt

[Alpha]

Free untested annoying dialog:

Code

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)