The 25 June 2008 build (5106) is out.

[denk_mal]

Hi,

i have a lot of toolbar clutter with the actual svn (5130). I have noticed it first in rev. 5126

If I move more than one toolbars into the same row only the first stays visibe after a view switch
or on restart of c::b. The menu says there are opened so I believe the first bar has moved all the other
bars out of the visible scope.

furthermore the settings for custom views (e.g debugging) aren't saved to disk; After a restart of c::b all settings are gone.

I've tried it with fresh settings by deleting default.conf but that make no difference.

Are there any other things I can do?

greetings
denk_mal

[LlubNek]

Besides the above, the debugger doesn't seem to keep track of the current build target and just dubugs the "Debug" target.  That's fine if you're using only "Debug" and "Release", but not when you have more than one actual target, like server vs. client, or test apps for specific features within a larger project.

[killerbot]

I found the cause for the memory-eating:
it's the optimization-flag.

I'm not an automake-guru, so it takes me a while to fin out how to switch it off only for headerfixup-plugin.
But at least it's quite easy.

Here is a patch for "Makefile.am" of headerfixup-plugin.
After applying it you have to run "./bootstrap" to regenerate "Makefile.in" what is used by "./configure".

Code

--- /usr/src/c/codeblocks/codeblocks-1.0svn/src/plugins/contrib/headerfixup/Makefile.am 2008-07-09 07:20:42.000000000 +0200
+++ codeblocks-1.0svn/src/plugins/contrib/headerfixup/Makefile.am       2008-07-10 23:05:33.000000000 +0200
@@ -2,6 +2,8 @@
            -I$(top_srcdir)/src/include \
            -I$(top_srcdir)/src/include/wxscintilla/include

+CXXFLAGS = @CXXFLAGS@ -O0
+
 libdir = $(pkgdatadir)/plugins

 lib_LTLIBRARIES = libheaderfixup.la

This will add a "-O0" (the second one is a zero) to "CXXFLAGS" and overrides the "-O2" set before. The other flags will not be touched.

svn now contains the hack, but only for 64 bit, right ?
I think a colleague of mine is having the same build issue but on 32 bit (ubuntu). I can only check this in 3 weeks time. But maybe it is best not to 'if' in the configure.in and Makefile.am, that way we can keep the hack very small, and located to 1 file with a minimum of logic ? After all it is just for a plug-in.

[pasgui]

I think a colleague of mine is having the same build issue but on 32 bit (ubuntu). I can only check this in 3 weeks time. But maybe it is best not to 'if' in the configure.in and Makefile.am, that way we can keep the hack very small, and located to 1 file with a minimum of logic ? After all it is just for a plug-in.

I have also applied the correction for ubuntu 32 bits for the two last nightly.

regards, pasgui

[Jenna]

http://forums.codeblocks.org/index.php/topic,8821.msg64075.html#msg64075

After a short test on my usb-stick (the only 32bit linux with an actual wxWidgets on it), I reverted conditional part of patch.

Takes about half the memory as on 64bit, and needs only 1.5 minutes.
But this is still too much for most build-systems and without optimizations it needs about 4 seconds to compile.