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 (http://forums.next.codeblocks.org/index.php/topic,3232.0.html).
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.next.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:
Debian stable packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo (https://apt.jenslody.de/).
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 (https://copr.fedoraproject.org/coprs/jenslody/).
I recently switched to copr (https://copr.fedoraproject.org/) to build and host my Fedora and CentOS packages.
Instructions how to use it can be found on my server (https://rpm.jenslody.de/) (easier) or on copr (https://copr.fedoraproject.org/coprs/jenslody/) (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.
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 ?
Sample project?
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.
Quote from: damorin on February 24, 2015, 01:45:03 PM
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
#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)
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".
Quote from: damorin on February 24, 2015, 02:56:27 PM
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.
when I use this nightly build to create a new console project , file -> new -> project -> console application ,
it shows, something seems wrong?
Quote from: huzhongshan on March 06, 2015, 12:29:42 PM
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.
Quote from: jens on March 06, 2015, 01:43:44 PM
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.
@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.
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/"));
Quote from: jens on March 06, 2015, 09:55:50 PM
@MortenMacFly (and others of course):
can you test this patch ?
This works now. Than you, Jens. Feel free to commit. :-)
Quote from: MortenMacFly on March 09, 2015, 07:55:43 AM
Quote from: jens on March 06, 2015, 09:55:50 PM
@MortenMacFly (and others of course):
can you test this patch ?
This works now. Than you, Jens. Feel free to commit. :-)
In trunk (svn r10136).
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.
Also I've a bug even on newer nightlies, sometimes I open a project in codeblocks and the "Build" icon (the gear) remains greyed, i.e. I can't click on it. When that happens I close codeblocks and reopen codeblocks + the project until it works (usually straightaway).
I dunno how to reproduce it but the icon is not greyed because there is a background compilation or because the built process is running, this happens even just after a reboot.