Code::Blocks

User forums => Nightly builds => Topic started by: killerbot on February 19, 2015, 09:36:56 pm

Title: The 19 February 2015 build (10122) is out.
Post by: killerbot on February 19, 2015, 09:36:56 pm
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.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:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 19 February 2015 build (10122) is out.
Post by: jens on February 20, 2015, 09:52:13 am
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.
Title: Re: The 19 February 2015 build (10122) is out.
Post by: damorin on February 23, 2015, 06:25:14 pm
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 ?



Title: Re: The 19 February 2015 build (10122) is out.
Post by: oBFusCATed on February 23, 2015, 07:41:13 pm
Sample project?
Title: Re: The 19 February 2015 build (10122) is out.
Post by: 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.

Title: Re: The 19 February 2015 build (10122) is out.
Post by: ollydbg on February 24, 2015, 02:27:00 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
Code: [Select]
#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)
Title: Re: The 19 February 2015 build (10122) is out.
Post by: damorin on February 24, 2015, 02:56:27 pm

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".












Title: Re: The 19 February 2015 build (10122) is out.
Post by: ollydbg on February 27, 2015, 01:57:28 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.
Title: Re: The 19 February 2015 build (10122) is out.
Post by: 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?
Title: Re: The 19 February 2015 build (10122) is out.
Post by: jens on March 06, 2015, 01:43:44 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.
Title: Re: The 19 February 2015 build (10122) is out.
Post by: MortenMacFly on March 06, 2015, 08:14:14 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.
Title: Re: The 19 February 2015 build (10122) is out.
Post by: jens on March 06, 2015, 09:55:50 pm
@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: [Select]
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/"));
Title: Re: The 19 February 2015 build (10122) is out.
Post by: MortenMacFly on March 09, 2015, 07:55:43 am
@MortenMacFly (and others of course):
can you test this patch ?
This works now. Than you, Jens. Feel free to commit. :-)
Title: Re: The 19 February 2015 build (10122) is out.
Post by: jens on March 09, 2015, 04:40:57 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).
Title: Re: The 19 February 2015 build (10122) is out.
Post by: teto on September 25, 2015, 05:55:53 pm
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.
Title: Re: The 19 February 2015 build (10122) is out.
Post by: teto on October 09, 2015, 08:57:55 pm
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.