The 09 July 2007 build (4241) 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_wx284.7z

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

The 09 July 2007 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20070709_rev4241_win32.7z
  - Linux :
   http://prdownload.berlios.de/codeblocks/CB_20070709_rev4241_Ubuntu6.10+7.04_wx2.8.4.deb
   http://prdownload.berlios.de/codeblocks/CB_20070709_rev4241_Debian4.0_wx2.8.4.deb
   http://prdownload.berlios.de/codeblocks/CB_20070709_rev4241_suse100-102.wx28.i586.rpm (not yet)
   http://prdownload.berlios.de/codeblocks/CB_20070709_rev4241_fc4+5.i586.rpm (not yet)


Resolved Fixed:

• Fixed: plugin installation wouldn't create directories on windows (thanks dje)
• Fixed crash when using "Close" or "Close all" in open files list context menu (bug #11508)
• envvars plugin: fixed "envvars not unset on project close" bug (thanks Yiannis)

Regressions/Confirmed/Annoying/Common bugs:

• toolbar-images-not-changing-state (is a wx problem/Win XP problem)

[Grom]

I have taken a look on to the roadmap in wiki. Do you update it sometimes or not?

[stahta01]

I have taken a look on to the roadmap in wiki. Do you update it sometimes or not?

Yes.

It was updated in last 90 days.

Tim S

[Xaviou]

Ubuntu 6.10 & 7.04 Amd64 .deb installer (build with wx263 and wx284) can be found here.

[marfi]

Hi,
I'm affraid that precompiled headers support for GCC (MinGW) in C::B is broken. Only default option in Project settings ('Generate PCH alongside original header') works properly (but this option is not suitable for projects with multiple targets or for a case you want to subversion your code).

Option 'Generate PCH in a directory alongside original headers' creates directory named like the precompile header file with PCHs for every target, but only one of them is then used thus the compiler skips the PCHs for all others targets and writes warning message like this:
cc1plus.exe: warning: ./wx_pch.h.gch/Debug DLL_wx_pch_h_gch: created using different flags (for example this message apears also for Release target even a file named Release DLL_wx_pch_h_gch realy exists, etc...).

The last project option 'Generate PCH in the object output dir' doesn't work at all; the PCH created in OBJ dir is allways skiped and the original headers are used instead for all project targets.

(I use Win XP SP2 OS and the latest nightly build)

[mandrav]

I'm affraid that precompiled headers support for GCC (MinGW) in C::B is broken.

No, it 's not broken.

Option 'Generate PCH in a directory alongside original headers' creates directory named like the precompile header file with PCHs for every target, but only one of them is then used thus the compiler skips the PCHs for all others targets and writes warning message like this:
cc1plus.exe: warning: ./wx_pch.h.gch/Debug DLL_wx_pch_h_gch: created using different flags (for example this message apears also for Release target even a file named Release DLL_wx_pch_h_gch realy exists, etc...).

That's normal. All PCHs (for every target) are generated in that dir. GCC picks up the correct one for each target but also displays a warning for the rest that it didn't use (which is normal). You can turn this warning off by removing the -Winvalid-pch option in your build options.

The last project option 'Generate PCH in the object output dir' doesn't work at all; the PCH created in OBJ dir is allways skiped and the original headers are used instead for all project targets.

You should know that the current dir has precedence over any search dirs added to the compiler (can be overridden with various tricks but none of them is boilerplate stuff we could do automatically). So, if you move your PCH header source file in a subdirectory instead of the root of your project tree, and reference it in your code like #include "some/pch.h", then the PCH from the object's output dir will be picked up correctly.

[stahta01]

The unofficial 4.x GCC builds has issues using some type PCH. I have no idea of the cause but one or two of the choices does not work quite right. This was true as of one or two months ago, I have not checked the new builds lately.

Tim S

[marfi]

To Mandrav:

First of all I'd like to thank you for your prompt answer. I tried your advices but I'm not sure it helped me. Compilation with both non-default PCH options takes much more time that the prefered (default) one (same(?) time like without PCH). Moreover, the compiler command line generated for 'Generate PCH in the object output dir' is quite strange (see highlighted text below):

mingw32-g++.exe -Wall -pipe -mthreads -Winvalid-pch -D__GNUWIN32__ -D__WXMSW__ -DwxUSE_UNICODE -DWX_PRECOMP -O2  -include pch\wx_pch_dll.h -DWXUSINGDLL  -I..\obj\Win-gcc\wxsfdemo\ReleaseDLL\pch -I- -I..\obj\Win-gcc\wxsfdemo\ReleaseDLL\pch -I. -ID:\Lib\wxMSW-2.8\include -ID:\Lib\wxMSW-2.8\contrib\include -I..\include -ID:\Lib\wxMSW-2.8\lib\gcc_dll\mswu -IC:\mingw\include  -c D:\MyWork\Source\VC++\wxSF\example\MainFrame.cpp -o ..\obj\Win-gcc\wxsfdemo\ReleaseDLL\MainFrame.o

[indigo0086]

There's a big problem when opening *.c files from the explorer (windows) when codeblocks isn't open.  If I try to codeblocks starts up and stays at the welcome screen, but explorer hangs and I can't bother the folder where I opened the file from.  I exit codeblocks and get the send/dns error message.

[Albenejean]

There's a big problem when opening *.c files from the explorer (windows) when codeblocks isn't open.  If I try to codeblocks starts up and stays at the welcome screen, but explorer hangs and I can't bother the folder where I opened the file from.  I exit codeblocks and get the send/dns error message.

Me too.
It's the last focused window that has this problem. For example, double clik on an .cbp file, the window containing this file hangs. When I open the same file with right click->"open with..."->"Choose a program", it is the "open with..." window that hangs.

I have to wait a 30-45 secs, then it's OK.

[EDIT]:
When I open a project from the windows explorer, and then immediatly closed CB, I receive sometimes an error from Windows that "Windows could not find the file xxx/MyProject.cbp, blablabla...". No error from CB, and it happens not always.

[EDIT2]: This is not a new bug. I have seen this in previously nightlies too.