Compiler Flags not saved (only after restart)

[kontrastblick]

I am running Code::Blocks svn build 8982 (Apr 12th 2013) on Windows 7 64bit. The compiler I use is gcc 4.7.3 (targeting m68k-elf or "coldfire").
My Project compiles fine with a custom Makefile, but I want to move to the Code::Blocks build system.


Currently I'm trying to add custom compiler flags, but it seems as they are not being saved.

Reproduction (2 minutes):
1. Open a random project (or create a new one).
2. Go to "Project"->"Build Options", then to "Compiler Options"->"Compiler Flags".
3. Add a random flag (right mouse button into the list view, then choose "new flag".
Name: foo
Compiler Flag: -s
Category: General options
=>Then click "OK"
The new compiler flag "foo [-s]" now shows up in the list.
4. Close the "Project build options" Dialog by clicking "OK".
5. Reopen the dialog "Project"->"Build Options".
6. The newly added compiler flag does NOT show up in the list now (I do expect it to show up here).

Workaround:
1. After adding the new compiler flag as described above, close the Code::Blocks IDE (File->Quit).
2. When asked "The perspective "Code::Blocks default" has been changed. Do you want to save it?" click YES.
3. Start Code::Blocks again
4. Re-open the project used before.
5. Open the dialog "Project"->"Build Options".
6. The newly added flag now shows up in the list.

Restarting Code::Blocks is necessary.
Neither selecting "View->Perspective->Save current" nor "Save Workspace" nor "Save all Projects" fixes the problem.


Questions:
1. Can you reproduce the problem described?
2. Is this a bug or expected behaviour?

Christoph

[oBFusCATed]

Restarting Code::Blocks is necessary.
Neither selecting "View->Perspective->Save current" nor "Save Workspace" nor "Save all Projects" fixes the problem.

These are not related to the any options, but only to the positions and visibilities of various dock-able windows in C::B.

[Alpha]

1. Can you reproduce the problem described?

Yes.

2. Is this a bug or expected behaviour?

Bug.

I am looking into the cause.

[Jan van den Borst]

I think this issue still is still present. Will it be fixed?

[oBFusCATed]

Someday probably.
Alpha would you have time to fix it? If not I can try to find some time.

[Alpha]

Apologies for losing track of this.  Please test the following patch:

Code

diff --git a/src/plugins/compilergcc/compileroptionsdlg.cpp b/src/plugins/compilergcc/compileroptionsdlg.cpp
index 611fd9f..4160228 100644
--- a/src/plugins/compilergcc/compileroptionsdlg.cpp
+++ b/src/plugins/compilergcc/compileroptionsdlg.cpp
@@ -1371,6 +1371,9 @@ void CompilerOptionsDlg::DoSaveCompilerDefinition()
     if (!wxDirExists(ConfigManager::GetFolder(sdDataUser) + wxT("/compilers")))
         wxMkdir(ConfigManager::GetFolder(sdDataUser) + wxT("/compilers"));
     doc.Save(ConfigManager::GetFolder(sdDataUser) + wxT("/compilers/options_") + compiler->GetID() + wxT(".xml"));
+
+    // update the in memory cache
+    compiler->SetOptions(m_Options);
 } // DoSaveCompilerDefinition
 
 // events

Edit: Looks like it may not be that simple.  (Possible issues with overwriting global enable compiler options.)

Edit 2: Or maybe not?  Needs more testing...

[Jan van den Borst]

This patch works for me!!

[oBFusCATed]

Push Alpha, push... 

[Alpha]

Committed r9845.  Hopefully no unforeseen side effects...

[White-Tiger]

Just sayin... I've already fixed that here: http://forums.codeblocks.org/index.php/topic,19008.msg130050.html
And my change works without a problem

Main difference is that I've removed the old "try" to set options (well, it had a note already because you knew it was wrong xD) and my newly added SetOptions was called in DoSaveCompilerDefinitionand not in DoSaveVars

[oBFusCATed]

Post a minimal patch and we can discuss it.

[White-Tiger]

well.... that patch was minimal^^ The main reason wasn't this fix xD Just fixed that anyway... And I've even commented it.. you can clearly see that it's only in the 2nd file... and there it's just 2 relevant lines out of 8.. so not hard to check (and less then 5 minutes of time, less time I would need to create a new one)
it's

Code

95 -    compiler->SetOptions(m_Options); //LDC : DOES NOT BELONG HERE !!!

and

Code

118 +    compiler->SetOptions(m_Options);

Patches have to be looked at anyway, so it doesn't change much.. either you understand what they do and apply them, understand what they do and properly implement them (because something was overlooked) or you don't understand and ignore them.. well a developer should always understand what's going on with his own program
Posting patches is work as well, unnecessary work and I've took about an hour to just post that one... fixing it was almost faster^^ (well not really.. that "save fix", yes, the other changes.. maybe not)

So stop complaining about "huge" patches (even tho that one isn't huge at all... it's even easy to understand) just addict yourself to you program (Code::Blocks) and try to improve it instead of ignoring stuff. You know.. this patching mechanism is a real problem with open source.. because patches aren't accepted in time and a lot good ones just ignored. And I don't mean Code::Blocks specifically.. I've checked multiple open source softwares and their patches.. some aren't accepted for years even though they fixed a "major" problem and seemed ok. Generally rather rewrite the patch when it fixes something than ignoring it all together. Guess why some people don't even bother to post patches It's mainly a waste of time. (Even more when you try to keep them "small")

One might have high requirements for feature adding patches... but not bug or major usability fixes

[oBFusCATed]

Minimal is subjective. But most of the times it means that a patch fixes one single thing and has a clear explanation what is fixing.

So if you still think that the current solution is not fine and can be improved please post a patch...