The 02 November 2012 build (8500) is out.

[oBFusCATed]

No, why should I?

Because you're writing non-standard code which will break with another compiler, which doesn't support GCC extensions probably.

[MortenMacFly]

Because you're writing non-standard code which will break with another compiler, which doesn't support GCC extensions probably.

OK - but I don't want to use another compiler and use several GCC extensions already because they are handy. But yes - its surely a portability issue.

[carra]

I can confirm that the fix for custom abbreviations is working correctly now: the empty extra lines are no longer inserted due to Windows line terminators "\r\n".

However, this bug persists when the abbreviations are using scripts! I don't really know why, since I thought script execution should be unaffected by this.

For instance, if you write this abbreviation under Windows (using the windows EOL):

Code Select Expand

[[ print("*line 1*\r\n*line 2*"); ]]

CodeBlocks 8500 prints the following:

Code Select Expand

*line 1*

*line 2*

While 8248 and previous correctly printed

Code Select Expand

*line 1*
*line 2*

Should I now change my scripts to Linux EOL '\n'? (and hope it won't break EOL consistency in my files)

EDIT: I have verified that the bug, however, does not happen if you execute that script line in the script console. So it has to do with abbreviations instead

[Alpha]

However, this bug persists when the abbreviations are using scripts! I don't really know why, since I thought script execution should be unaffected by this.

That does not make sense... I will see if I can figure out why.

Should I now change my scripts to Linux EOL '\n'? (and hope it won't break EOL consistency in my files)

Yes, this is the recommended (by me ) method; code generation will match the editor's current EOL style just before insertion (if you would like to double check, set EditorTweaks to show EOL characters).

[shurick]

Packages for openSUSE 12.1, openSUSE 12.2 (binaries and sources) for 32-bit and 64-bit.

[gd_on]

I have a small problem when I build a recent svn version (8523) under windows : exchndl.dll does not seem to be build when I make a full All build (with CodeBlocks.workspace or more precisely CodeBlocks.cbp).
It is built only if I select specifically as Build target ... "exchndl". Is it normal ?

gd_on

[MortenMacFly]

It is built only if I select specifically as Build target ... "exchndl". Is it normal ?

Yes, it has been disabled for several reasons, one is it broke builds on some systems as people were unable to have the pre-requisites required for this target. To avoid noise we disabled it in "All". Hence you need this DLL for the crash report to work correctly. But its enough if you compile it one time explicitly once you have changed the compiler.

[gd_on]

Thanks for the reply

gd_on

[killerbot]

It is built only if I select specifically as Build target ... "exchndl". Is it normal ?

Yes, it has been disabled for several reasons, one is it broke builds on some systems as people were unable to have the pre-requisites required for this target. To avoid noise we disabled it in "All". Hence you need this DLL for the crash report to work correctly. But its enough if you compile it one time explicitly once you have changed the compiler.

which reminds me, I was going to provide a new version, and forgot  :-\

[gd_on]

Thanks for patch in svn 8519 : I'm (we are !) now able to generate fortran code with modules with multi-thread. Before, it worked properly only in mono-thread because modules in fortran are a little bit specials : two files are generated, a classic .o file and a .mod file. This last one may be/is necessary at compile time in other routines/modules, so in multi-threading, you might need a .mod file before the end of it's own build. Now, with the new priority gestion, it's solved since svn 8519.
Thanks again.

gd_on

[ollydbg]

The bad thing is: if I rebuild C::B, I will sometimes see the warning message(see below)

Does this mean that my "PATH" was locked by some one/software?

I found a workaround, for those who have the same issue, you can give C::B a new and clean environment, like, start C::B in the console with the command:

Code Select Expand


@set PATH=E:\code\common_bin;C:\Program Files\SlikSvn\bin
start codeblocks.exe


Here, the PATH variable is set manually, and my c::b build and works fine.

I guess that my PATH have too many strings, which cause the SetEnvironmentVariable function fail.

[White-Tiger]

well this isn't about this specific nightly... but rather revision 8536, it simply breaks the windows build^^
It's not possible to define "unused" as this is often a variable name used with windows. eg. in "winnt.h" it is used for the "DECLARE_HANDLE" define. (MinGW64)

[oBFusCATed]

White-Tiger: http://forums.next.codeblocks.org/index.php/topic,17067.msg116546/topicseen.html#msg116546

[gd_on]

Something new in svn 8549 (or a bug ?), but, under Windows 7, an AppData has been created in my Program files (x86)\codeblocks folder and my previous default.conf is not found. Apparently, it's in this new folder that C::B parameters are stored. Is it normal ?
After reverting to svn 8543, everything is OK again. Is it a bug ? a new behaviour ? But, in that last case, if Program files is write protected, a standard behaviour in Windows 7, I'm not sure it's a good idea : within the user's profile it's better.

gd_on

Edit : I have made a full rebuild and an install in a clean empty folder, and everything is OK with svn 8549. Strange. Sorry for the noise !

[AndyJ]

Thanks for all the great work recently!

I noticed a few nightlies back that on my 2 monitor Win-XP system CodeBlocks no longer remembers that it was last run maximised on my 2nd monitor (this used to work). It did however remember that it was on the the 2nd monitor if not maximised. With the latest nightly, it now always seems to start on my primary monitor regardless of where it was when it was last closed - any ideas?

Andy

Edit: Oops, this really applies to the Nov 11th nightly (which now seems to have become something different...)