The 13 October 2012 build (8455) is out.

[killerbot]

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works.

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2812_gcc452-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc452-TDM.7z

The 13 October 2012 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20121013_rev8455_win32.7z
  - Linux :
   none

Resolved Fixed:

• debugger: Fix the ToggleBreakpoint function to work correctly with multiple debugger plugins;
• debugger: Fix the remove operation in the breakpoints dialog to correctly refresh the markers;
• debugger: Implement proper adjusting of breakpoints, when lines have been added/removed in the editor;
• debugger: Add API function to remove all breakpoints correctly;
• debugger: Sanitize user input to prevent debugger stalls, caused by the character '\' at the end of the GDB command;
• debugger: Detect changes of the symbol of a watch inside the AddWatch call (related to the prev commit);
• fixed bug #18752: Invalid handling of UNC path's in workspace (and project) files
• applied patch #3347: SmartIndent: more smart indenting by ALPHA
• applied patch #3347: SmartIndent: more smart indenting (2) by ALPHA
• SmartIndent-plugin (linux): added XML-plugin to automake-system and contrib-plugins list for debian and rpm-base systems
• Find/Replace: remember search path, wild cards etc for find/replace in path (regression) (Thanks Alpha for the patch, rickg for the report)

Regressions/Confirmed/Annoying/Common bugs:

[Jenna]

As usual:
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo.
Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc16, fc17 and fc18) and RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) can be found in my rpm-repo .

[headkase]

I'm sorry if I missed a previous thread on the following topic.

The latest stable release of Code::Blocks is 10.05.  So, fifth month of 2010.  If you are on Windows this isn't a problem as you always have the option to use one of the nightlies.  On Linux, the many flavors, things become a bit more complicated.  Very few Linux distributions package "up to the minute" versions of software.  On those, excluding Debian, Fedora, and the repo for Ubuntu you can find if your look hard enough, it usually falls into two choices: stick with 10.05 because that is what is in your distributions repositories - the latest stable version, or manually "./configure, make, make install."  Sticking with a repository version gives you a completely obsolete version of C::B compared to a nightly.  Manually compiling your own doesn't integrate well with most package managers and you risk making your system unstable through the many conflicts that can cause.  Do you think that two years and five months is a long enough time from the last stable release that choosing any recent nightly and polishing it for a bit to create a new stable release would be a good thing to do?

I don't fall into Debian, Fedora, or Ubuntu.  I'm Arch Linux.  So the graciously provided Linux repos don't work for me.  I am lucky however that a build script exists in Arch's User Repositories so I can build a package that will not corrupt my system.  For all the hundreds of flavors of other Linuxes however that will not always be the case.

Code::Blocks is a highly refined piece of software, but 10.05 is what most of the Linux world sees.

[oBFusCATed]

You get the standard answer - when it is ready. Hopefully soon, but don't count on it.

[headkase]

Thank you. I'll keep my eyes peeled for possible further developments..

[piityy]

Greetings,
thanks for great job.
svn8455 build on W7x64 for embeded devices development (with gnu arm gcc).

Code is marked as "inactive" when symbol which makes code "active" is defined in other (but included) file.
Note that symbol can also be defined globaly (in compiler settings/project build options) - this don't work as well.

Structure members listing issues:
Example:

Code Select Expand

// GPIO_TypeDef is a structure defined using typedef
#define GPIOB_BASE_ ((((uint32_t)0x40000000) + 0x10000) + 0x0C00)
#define GPIOB_ ((GPIO_TypeDef *) GPIOB_BASE_) // ST Micro defines peripheral registers this way
GPIO_TypeDef *pStr = (GPIO_TypeDef *) GPIOB_BASE_;
// access to pointers:
pStr-> // shows up members - ok
((GPIO_TypeDef *) GPIOB_BASE_)-> // shows up members - ok
((GPIO_TypeDef *) ((((uint32_t)0x40000000) + 0x10000) + 0x0C00))-> // only displays type ("GPIO_TypeDef" - typedef image)
GPIOB_-> // no reaction

When "find declaration" is used more than 1 times, message window "Multiple matches" is displayed. Each next call of "find declaration" adds one line in selection list.
Example:
#define B   0
B;   // -> use "find declaration of: B"

When I create custom color in syntax highliting color dialog, no custom color apears when color dialog is reinvoked (all fields are reset to white).

[gd_on]

I have an "old" plugin (cbMakegen) which does not compile any more with last svn 8462. A class is missing :

Code Select Expand

||=== Code::Blocks wx2.8.x, src ===|
D:\gdurand\Documents\svn_CodeBlocks\CodeBlocks_src\trunk\src\src\breakpointsdlg.cpp|10|warning: .objs\include/sdk_precomp.h.gch: not used because `EXPORT_LIB' not defined [-Winvalid-pch]|
||=== wxWidgets - Contrib Items, wxFlatNoteBook ===|
wxFlatNotebook\include\wx\wxFlatNotebook\xh_fnb.h|24|warning: type attributes ignored after type is already defined [-Wattributes]|
||=== cbmakegen, default ===|
D:\gdurand\Documents\svn_CodeBlocks\CodeBlocks_src\trunk\src\plugins\contrib\CBMakeGen\Makefile.cpp||In member function 'bool cbMGMakefile::formFileForTarget(ProjectBuildTarget*, wxTextFile&)':|
D:\gdurand\Documents\svn_CodeBlocks\CodeBlocks_src\trunk\src\plugins\contrib\CBMakeGen\Makefile.cpp|470|error: 'class Compiler' has no member named 'GenerateCommandLine'|
D:\gdurand\Documents\svn_CodeBlocks\CodeBlocks_src\trunk\src\plugins\contrib\CBMakeGen\Makefile.cpp|557|error: 'class Compiler' has no member named 'GenerateCommandLine'|
||=== Génération terminée : 2 erreurs, 2 avertissements (17 minutes, 2 secondes) ===|

I think, it's probably a modification introduced in svn 8457 where the GenerateCommandLine has been suppressed (at least in compiler.h and compiler.cpp).
Is this a definitive suppression ? is there a way to replace this functionality ?
Or shall i have to abandon this plugin with is no longer maintained by the author, but that I used from time to time ?

gd_on

[oBFusCATed]

Yes, there is not turning back.

The plugin should be ported to the new API.
You have to call Compiler::GetCommandGenerator or something like that. Look at the changes in the revision to see what is needed.

p.s. As far as I know (not from personal experience) cbp2make is working better.

[MortenMacFly]

I have an "old" plugin (cbMakegen) which does not compile any more with last svn 8462.

Use the file attached to replace with the one of the plugin.

The plugin should be ported to the new API.

@oBFusCATed: You see: I told you! ;D ;D ;D

p.s. As far as I know (not from personal experience) cbp2make is working better.

True.

[oBFusCATed]

@oBFusCATed: You see: I told you! ;D ;D ;D

:

[Martin K.]

@oBFusCATed: You see: I told you! ;D ;D ;D

:

I think i know what you told him...
Yesterday I stumbled upon it, but i have to continue to support the old version also.

BTW: The SDK version has not changed, right?

Martin

[oBFusCATed]

BTW: The SDK version has not changed, right?

I would have changed it, but I messed the merging...

[gd_on]

OK. Dowloaded and tested. 
Thanks.
cbp2make is better, sure, but this small plugin is not so bad. And, it's a plugin, not a standalone soft.

gd_on

[nvanwyen]

.
I see a lot of people are asking about the "cbMakeGen", because the new SDK broke the 0.3 version.  This happens due to a change in the Compiler class, which no longer supports the "GenerateCommandLine" API; you must now use the "CompilerCommandGenerator" instead.

If you want a working copy of the new plugin, modified for C::B 12.11 please feel free to contact me. I'll be submitting my changes to the cbMakeGen author shortly.

.