The 17 May 2012 build (7966) 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 17 May 2012 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20120517_rev7966_win32.7z
  - Linux :
   none

Resolved Fixed:

• docu: first update of documentation (made it compile under WinEdt)
• Debugger plugin: detecting the PID value by parsing the "[New Thread 2684.0xf40]" like string under MinGW GDB, this avoid to set on/off the debugevents when debugger plugin started and simplify the logic. See: http://forums.codeblocks.org/index.php/topic,16159.msg109092.html#msg109092 for more details.
• fixed layout issues on certain platfoms (see here: http://forums.codeblocks.org/index.php/topic,15376.0.html)
• sdk: Added FindProjectForFile function to the ProjectManager, useful when one needs to find the project for a given file. Refactored the code to use the new function;
• debugger: Speed up workspace loading/closing (thanks Pecan);
• save/load dynamic link library lib name and def file into project file -> *backward compatible* change in project file
• finalised re-work of debugger settings dialog so it sizes correctly (fist file already got committed in r7940 by accident)
• abbreviations plugin: applied patch by Neil Butterworth (see http://forums.codeblocks.org/index.php/topic,15450.0.html)
• abbreviations pluginlist abbreviations in alphabetic order + cursor visible in the abbreviation code editor
• readded close with middle-click on editor- and infopane-tabs, accidently lost in commit 7911
• fixed eol-style issues: Added svn:eol-style=native to all files, used the dos2unix tool for some of the broken files (see r7945)
• fixed regression with import library generation as reported here: http://forums.codeblocks.org/index.php/topic,16199.msg110084.html
• optimised writing import library name only in case it differs from the default value (as with all other options)
• optimised layout of debugger dialogs (in core) -> should be centered properly now.
• fixed word wrap mode not selectable as reported here: http://forums.codeblocks.org/index.php/topic,15883.0
• Improved the UI for the first time C::B is started and there is no default.conf file
• Fix Bug #18534 "Functions returning T* are displayed as returning T", use the m_FullType instead of m_BaseType, so the call-tip shows correctly when the user enter a left parenthesis.
• update of wxSmithSTC to STEdit from v1.2.6 to v1.6.0
• CppCheck: Applied patch by Alpha: Proper macro replacement in case of virtual target present

Regressions/Confirmed/Annoying/Common bugs:

[Grom]

What about a new official release?

[stahta01]

What about a new official release?

As long as the SDK API is being changed; it is unlikely for them to do a new official release.
Or in the standard reply, "When it is ready."

Tim S.

[fubo]

Bug #18557 still there. Going back to 7789.

[oBFusCATed]

http://wiki.codeblocks.org/index.php?title=FAQ-General#Q:_When_will_the_next_stable_version_of_Code::Blocks_be_released.3F

[oBFusCATed]

fubo: If you've followed the discussion in the previous nightly build topic, you would have known that this is a feature and it won't be fixed. Sorry.

If you need something not available in the current variables you have to ask for it otherwise you'd be stuck in 7789 forever.

[fubo]

fubo: If you've followed the discussion in the previous nightly build topic, you would have known that this is a feature and it won't be fixed. Sorry.

If you need something not available in the current variables you have to ask for it otherwise you'd be stuck in 7789 forever.

Ok, so let's accept that was an unwanted feature = a bug up to version 7789. If I understood correctly, all variables exposed here can be used in option pane?
And, if I define some variables, can they be used in option pane?
Or no variables are usable?

[oBFusCATed]

Yes, you can.
See here: http://wiki.codeblocks.org/index.php?title=Global_compiler_variables
And here: http://wiki.codeblocks.org/index.php?title=Environment_Variables_plugin

[fubo]

Yes, you can.
See here: http://wiki.codeblocks.org/index.php?title=Global_compiler_variables
And here: http://wiki.codeblocks.org/index.php?title=Environment_Variables_plugin

Thank you so much! Changing $exe_dir\$exe_name.txt to $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).txt worked like a charm!

[oBFusCATed]

Happy it is working now

[NilC]

Four things:

0. Sorry for my English

1. C++11 & AStyle bug
As you surely know, there is "range-based for loop" in C++11:
for (int & x : a)
{
}

AStyle think that it's a label, because of colons and places it in the beginning of the line, so...
file "ASBeautifier.cpp" line "2376"
else if (isJavaStyle() && lastLineHeader == &AS_FOR)
The condition "isJavaStyle()" is no longer needed.

2. "Activate Project" Command

I have about 10 projects in workspace, when I activate some project - sometimes code::blocks freeze for ~5 second, once it freeze forever.
This bug appeared in nightly builds, following the 7790 (7790 if fine). I'm already posts info about this bug, but no one cares
Trying to fix by myself.

3. O_o WTF??

Guys, why the hell do you using targets (like Debug, Release, Win32, Linux in normal way) instead of using projects?

[oBFusCATed]

Guys, why the hell do you using targets (like Debug, Release, Win32, Linux in normal way) instead of using projects?

What targets?
You're free to use whatever fits your way of doing things...

[NilC]

Guys, why the hell do you using targets (like Debug, Release, Win32, Linux in normal way) instead of using projects?

What targets?
You're free to use whatever fits your way of doing things...

Putting all code in a one pot, and then get some of its parts with the targets - it's a perversion IMHO (But I'm not alone who think so).
Take a look (~350 KB)
http://dl.dropbox.com/u/58962113/Bru.png
http://dl.dropbox.com/u/58962113/CodeBlocks.png

[oBFusCATed]

No one stops you from using a single target. At work I do just that.
I don't see a problem here.

[MortenMacFly]

I don't see a problem here.

I don't, too. In the C::b project case, it bundles nicely related SDK libs, the SDK itself, the main app and some plugins into one project. The build order is from top to bottom and if you want, you can select just several targets of those using virtual targets (what we do). So this is another, but valid concept how to use targets. You don't have to do it that way, of course. All contrib plugins do it different for example.