User forums > Nightly builds

The 27 November 2010 build (6863) is out.

(1/8) > >>

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_wx2810_gcc441.7z

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

The 27 November 2010 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20101127_rev6863_win32.7z
  - Linux :
   none

Resolved Fixed:


* wxSmith-plugin: fix for a crash described here: http://forums.codeblocks.org/index.php/topic,13672.msg92143.html#msg92143 (until we find a better solution)
* improved wxWidgets wizard script, support selected CRT type
* fix an issue where external outdated external dependencies are not recognized (see http://forums.codeblocks.org/index.php/topic,13594.msg92496.html#msg92496 for detail)
* fix an issue due to changed behaviour of wxWidgets on some 64-bit systems (at least FEDORA 14 64-bit) see here: http://forums.codeblocks.org/index.php/topic,13734.msg92546.html#msg92546 for details
* added Yuchen Deng, alias "Loaden" to the list of developers
* fix an issue of the disassembly-dialog on linux: if the embedded wxSintilla-window is created with wxDefaultSize, parts of the dialog are hidden, if it is smaller than a certain size (e.g. if it is docked)
Regressions/Confirmed/Annoying/Common bugs:

Jenna:
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo.

buub0nik:
I'm having problems with global variables in the project's compiler search directories.  Any global variables used there get dereferenced into what they point to instead of staying as the global variable name. This is troublesome on shared projects with different development environments and having to edit the project file every update.  I am using svn 6862 but believe the problem has been present for a couple of weeks now. Example:

Global Variable: libfoo
base: ~/code/lib/foo
include: ~/code/lib/foo/include

Then setting Project->Build Options->Search Directories->Compiler to: $(#libfoo.include)  it will shortly change to ~/code/lib/foo/include

It seems to only affect the project's overall search directories, and only in the Compiler category. Individual build targets are unaffected.

Jenna:

--- Quote from: buub0nik on December 01, 2010, 08:24:12 pm ---I'm having problems with global variables in the project's compiler search directories.  Any global variables used there get dereferenced into what they point to instead of staying as the global variable name. This is troublesome on shared projects with different development environments and having to edit the project file every update.  I am using svn 6862 but believe the problem has been present for a couple of weeks now. Example:

Global Variable: libfoo
base: ~/code/lib/foo
include: ~/code/lib/foo/include

Then setting Project->Build Options->Search Directories->Compiler to: $(#libfoo.include)  it will shortly change to ~/code/lib/foo/include

It seems to only affect the project's overall search directories, and only in the Compiler category. Individual build targets are unaffected.

--- End quote ---
I just tested it on linux with a simple "Hello world" - project and the variables are not dereferenced, if I save the project.

I attach the project-file.

ahui886:
thanks

Navigation

[0] Message Index

[#] Next page