The 25 October 2020 build (12214) is out.

[killerbot]

new PATCHED wx dll , please download these too and replace your old ones !!!

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(s) for Code::Blocks : https://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw31u_gcc_cb_wx313_2D_gcc810-mingw64-2.7z
A link to Mingw64 dll's needed by Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/Mingw64dlls8.1.0.7z


The 25 October 2020 build is out.
  - Windows :
   THIS NIGHTLY HAS BEEN REMOVED, IT BREAKS A LOT OF PROJECTS
  - Linux :
   none

The current SDK version is : 2.4.0

Resolved Fixed:

• CC: Don't provide completions for unsupported files (ticket #1019)
• compiler: Parse correctly newer formats emitted by the IAR compiler (thanks Alatar)
• debugger: Use absolute paths when getting the backtraces with GDB
• Project Menu: Do not show "Notes" and "Set programs' arguments" if not project is open (Ticket #998, thanks Miguel Gimenez
• MacrosManager - Fix: do not clobber $text that is not a CB macro. See: http://forums.codeblocks.org/index.php/topic,24192

Regressions/Confirmed/Annoying/Common bugs:

[killerbot]

I think there might be something wrong with the Fortran Project, I get the following log messages "

FortranProject
FortranProject plugin error: file E:\Codeblocks\src\output31_64\share\codeblocks/images/fortranproject/fortran_intrinsic_modules.f90 was not found.
FortranProject plugin error: file E:\Codeblocks\src\output31_64\share\codeblocks/images/fortranproject/fortran_procedures.f90 was not found.

[J.]

MacrosManager - Fix: do not clobber $text that is not a CB macro. See: http://forums.codeblocks.org/index.php/topic,24192

This fix breaks existing configuration of CB itself and CB projects and it would sadly make project specific variables almost obsolete: E.g., a variable in a macro which is not defined was and should be expected to be replaced by the empty string (as already suspected by oBFusCATed in the thread mentioned above). 

It would be helpful it this was revisited.  ... reverting to CB_20201003.

[oBFusCATed]

@j. Can you describe the steps which lead to a breakage for you?

[MortenMacFly]

This fix breaks existing configuration of CB itself

I can confirm that. The patch introduces a serious regression:

If you have setup your compilers like $(CODEBLOCKS)\MinGW becasue it shall be portable, the executable is no longer found and you see in the log messages like:
NativeParser::SafeExecute: Invalid application command: $(CODEBLOCKS)\MinGW\bin\g++.exe

As you can see, at least the macro $(CODEBLOCKS) to the portable installation folder is no longer translated.

[MortenMacFly]

...I can also confirm that reverting r12214 fixes the regression. So I am voting to wither revert r12214 or Pecan comes up with a proper fix. We also have tools to test macrosmanager's functionality... just as a reminder. ;-)

Unfortunately, this also broke compiling C::B with C::B for me. Luckily I had a backup. Phew...

[J.]

@j. Can you describe the steps which lead to a breakage for you?

Sure - please see the simple example attached; run the target DEBUG to see that a non-defined variable is NOT expanded to an empty string.

As already mentioned by others above the compilation of CB with a CB project should fail, too.  Please note that the issue is same for non-defined variables contained in compiler macro strings, since I believe that the macro manager is impacted by the patch.

[killerbot]

with the latest commits of today, I can no longer build CB

Code

[  8.8%] g++.exe -Wall -g -pipe -mthreads -m64 -fmessage-length=0 -fexceptions -std=gnu++11 -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DNOPCH -DwxUSE_UNICODE -D_WIN64 -D__WX__ -DWINVER=0x0501 -DLINK_LEXERS -DSCI_LEXER -DWXMAKINGDLL_SCI -std=c++11 -Wno-unused-local-typedefs -Wno-deprecated-declarations -IE:\Development\wxWidgets-3.1.3\include -IE:\Development\wxWidgets-3.1.3\lib\gcc_dll$(WX_CFG)\mswu -Isdk\wxscintilla\include -Iinclude\tinyxml -Isdk\wxscintilla\src\scintilla\include -Isdk\wxscintilla\src\scintilla\src -Isdk\wxscintilla\src\scintilla\lexlib -c E:\Codeblocks\src\sdk\wxscintilla\src\scintilla\lexers\LexConf.cxx -o .objs31_64\sdk\wxscintilla\src\scintilla\lexers\LexConf.o
In file included from E:\Development\wxWidgets-3.1.3\include/wx/defs.h:45,
                 from E:\Development\wxWidgets-3.1.3\include/wx/wxprec.h:12,
                 from E:\Codeblocks\src\sdk\wxscintilla\src\PlatWX.cpp:8:
E:\Development\wxWidgets-3.1.3\include/wx/platform.h:154:10: fatal error: wx/setup.h: No such file or directory
 #include "wx/setup.h"
          ^~~~~~~~~~~~
compilation terminated.

[oBFusCATed]

@killerbot: Which commit in particular? Are you using the latest night build or the one before it?

[killerbot]

this is by using the nightly kicked out this morning, and taking in the commits that happened this afternoon.

Are you hinting that this nightly is actually broken due to that macro manager ?

[oBFusCATed]

This is what other people are reporting, I've not tried it yet. But I wouldn't be surprised

[J.]

@killerbot  The code line you provided breaks because the variable $(WX_CFG) used, but not defined in the project file is not expanded to an empty string. This is exactly the issue reported in the first place.

@oBFusCATed The (really) minimum example I attached above to help you check the implementation can well serve as a first test case.  It reveals exactly the very situation of using a non-defined variable.

[oBFusCATed]

The sample is not for me. I'm waiting Pecan to do something about this problem. If I don't hear anything from him soon, I'll just revert.

[Pecan]

The sample is not for me. I'm waiting Pecan to do something about this problem. If I don't hear anything from him soon, I'll just revert.

I'll revert 12214.