The 19 February 2015 build (10122) 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://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw28u_gcc_cb_wx2812_gcc492-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/mingwm10_gcc492-TDM.7z

The 19 February 2015 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2015/CB_20150219_rev10122_win32.7z
  - Linux :
   none

The current SDK version is : 1.24.0

Resolved Fixed:

• FileManager: adds checkbox to view only changed files from the last commit in a version controlled directory. Also fixes a couple of bugs with mercurial repo browsing and some issues reported by blauzahn at http://forums.codeblocks.org/index.php/topic,19961.msg136598.html#msg136598
• FileManager: retrieve only relative paths when showing changes to a directory under version control

Regressions/Confirmed/Annoying/Common bugs:

[Jenna]

Debian stable 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 (fc20, fc21 and rawhide), RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) and RedHat/CentOS 7 packages (only 64-bit at the moment) can be found in my rpm-repo.
I recently switched to copr to build and host my Fedora and CentOS packages.
Instructions how to use it can be found on my server (easier) or on copr (a little more handwork needed).

By the way:
users who did not add my rpm-repo manually but by downloading the appropriate rpm (with my repo-file inside) should get an automatic update to the new repo.

NOTE:
rawhide packages seem to be broken at the moment, due to a library mismatch between "real" rawhide-systems and the (mock-based) build-system.

[damorin]

Hi,

I noticed that all symbols in .h files (like ./src/h/) are not parsed unless the path is added to the "Project/targets options". All others symbols defined in C/C++ files are OK.

Is this normal ?

[oBFusCATed]

Sample project?

[damorin]

See attached the project compressed.

How to reproduce:

- Open the project Test.
- Open only src/test.c
- Right-click on "THIS_IS_A_TEST" and "Find declaration"
- Result is "Not found: THIS_IS_A_TEST" but it's defined in h/test.h which is part of the project but doesn't not appear in the Symbols.

[ollydbg]

See attached the project compressed.

How to reproduce:

- Open the project Test.
- Open only src/test.c
- Right-click on "THIS_IS_A_TEST" and "Find declaration"
- Result is "Not found: THIS_IS_A_TEST" but it's defined in h/test.h which is part of the project but doesn't not appear in the Symbols.

You should add one line

Code

#include "../h/test.h"

in the head of test.c.

If a header file is not included in any cpp files(translate files), then it will not be parsed. (CC used to parse the header files in project, but the behavior was changed later. I remember there was a change to let the parser follow all the #include directives about several months ago)

[damorin]

I added:

#include "test.h"

and I set the C/C++ parser to include the path to h and now it's working.

Just to make it easier, can the error message be "Not found, check the C/C++ parser path".

[ollydbg]

Just to make it easier, can the error message be "Not found, check the C/C++ parser path".

No, This is only one reason a token is not found, you may have other reasons which cause the error message.

[huzhongshan]

when I use this nightly build to create a new console project ,  file -> new -> project -> console application ,
it shows, something seems wrong?

[Jenna]

when I use this nightly build to create a new console project ,  file -> new -> project -> console application ,
it shows, something seems wrong?

See here for a solution/workaround.

This is definitely a bug, probably introduced by changes done by me.
I will look into it, when I'm back from work.

If the "default.conf" is in the standard-folder ("%APPDATA%\CodeBlocks") it should not happen.

[MortenMacFly]

If the "default.conf" is in the standard-folder ("%APPDATA%\CodeBlocks") it should not happen.

Oh well, I can reproduce this on my machine as well. Using any wizard will overwrite the original wizard sources. This is definitely a bug.

This happens to me with a "portable" C;::B (default.conf besides codeblocks.exe) on Windows.

[Jenna]

@MortenMacFly (and others of course):
can you test this patch ?
It works on linux, if C::B is build by C::B and default.conf is in the exe-folder.

The problem is that the user- and global-datapath are the same in this case.
The patch avoids this by adding the user-id (login-name) to the user-datapath.

Code

Index: src/sdk/configmanager.cpp
===================================================================
--- src/sdk/configmanager.cpp
+++ src/sdk/configmanager.cpp
@@ -25,6 +25,7 @@
 #include <wx/url.h>
 #include <wx/stream.h>
 #include <wx/stdpaths.h>
+#include <wx/filename.h>

 #ifdef __WXMSW__
 #include <shlobj.h>
@@ -1529,6 +1530,11 @@

     ConfigManager::data_path_user = dataPathUser + wxFILE_SEP_PATH + _T("codeblocks");

+    // if user- and global-datapath are the same (can happen in portable mode) we run in conflicts
+    // so we extend the user-datapath with the users name
+    if (wxFileName(ConfigManager::data_path_user) == wxFileName(ConfigManager::data_path_global))
+        ConfigManager::data_path_user.append(_(".")+wxGetUserId());
+
     CreateDirRecursively(ConfigManager::config_folder);
     CreateDirRecursively(ConfigManager::data_path_user   + _T("/plugins/"));
     CreateDir(ConfigManager::data_path_user   + _T("/scripts/"));

[MortenMacFly]

@MortenMacFly (and others of course):
can you test this patch ?

This works now. Than you, Jens. Feel free to commit. :-)

[Jenna]

@MortenMacFly (and others of course):
can you test this patch ?

This works now. Than you, Jens. Feel free to commit. :-)

In trunk (svn r10136).

[teto]

I use this nightly and I can't use middleclick on linux to paste code selected from codeblocks. I can't upgrade to newer nightlies since they create other problems (as reported in another thread). I wonder if there is something in the config that could have possibly disabled this or if it's a bug.
middle click pasting works for my other applications.