I see a wired bug, When I try to use this nightly build version to build the cb, I have such build error:
-------------- Build: tinyXML in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
-------------- Build: AutoRevision in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
-------------- Build: ConsoleRunner in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
-------------- Build: Squirrel in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
-------------- Build: Squirrel std lib in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
-------------- Build: SqPlus in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
-------------- Build: scintilla in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
-------------- Build: wxpropgrid in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
[100.0%] Running target pre-build steps
build_tools/autorevision/autorevision +wx +int +t . include/autorevision.h
'svn' is not recognized as an internal or external command,
operable program or batch file.
'git' is not recognized as an internal or external command,
operable program or batch file.
'svn' is not recognized as an internal or external command,
operable program or batch file.
-------------- Build: sdk in Code::Blocks wx2.8.x (compiler: GNU GCC Compiler)---------------
Target is up to date.
[ 33.3%] Running target post-build steps
[ 66.7%] cmd /c if not exist devel\share\CodeBlocks mkdir devel\share\CodeBlocks
[100.0%] zip -jq9 devel\share\CodeBlocks\manager_resources.zip sdk\resources\*.xrc
cmd /c "cd sdk\resources & zip -0 -q ..\..\devel\share\CodeBlocks\manager_resources.zip images\*.png images\12x12\*.png images\16x16\*.png"
'zip' is not recognized as an internal or external command,
operable program or batch file.
Process terminated with status 1 (0 minutes, 4 seconds)
0 errors, 0 warnings (0 minutes, 4 seconds)
But I have "zip" and "svn" command in my PATH, see the log:
C:\>which svn
C:\Program Files\SlikSvn\bin\svn.EXE
C:\>which zip
E:\code\common_bin\zip.EXE
C:\>
So, I suspect the PATH variable was sometimes changed by compiler plugin? I will check an old nightly build version.
This line is a bit strange:
char buffer[stl_putenv_var.length()+1];
because this is not a valid c++, but probably uses some language extension of gcc.
About the issue: have you looked at the code of wxsetenv? What does it do?
Have this problem been reported to wx devs?
They think it is fixed: http://trac.wxwidgets.org/ticket/1413
This line is a bit strange:
char buffer[stl_putenv_var.length()+1];
because this is not a valid c++, but probably uses some language extension of gcc.
Maybe, morten can say something about this.
About the issue: have you looked at the code of wxsetenv? What does it do?
see below:
bool wxSetEnv(const wxString& WXUNUSED_IN_WINCE(var),
const wxChar *WXUNUSED_IN_WINCE(value))
{
// some compilers have putenv() or _putenv() or _wputenv() but it's better
// to always use Win32 function directly instead of dealing with them
#ifdef __WXWINCE__
// no environment variables under CE
return false;
#else
if ( !::SetEnvironmentVariable(var, value) )
{
wxLogLastError(_T("SetEnvironmentVariable"));
return false;
}
return true;
#endif
}
I can not see any reason why SetEnvironmentVariable failed.
Have this problem been reported to wx devs?
I will report it if I have time.
They think it is fixed: http://trac.wxwidgets.org/ticket/1413
It said:
Changed 4 years ago by neis
Fixed by revision 42471, which should have ensured that it's correct in 2.8.0 and later.
But it appears that the bug is still here in wx2.8.12.
Edit:
See here: http://docs.wxwidgets.org/2.9.3/group__group__funcmacro__env.html
bool wxSetEnv ( const wxString & var,
const wxString & value
)
Sets the value of the environment variable var (adding it if necessary) to value.
Notice that under Windows platforms the program may have two different environment blocks: the first one is that of a Windows process and is always present, but the CRT may maintain its own independent copy of the environment. wxSetEnv() will always update the first copy, which means that wxGetEnv(), which uses it directly, will always return the expected value after this call. But wxSetEnv() only updates the second copy for some compilers/CRT implementations (currently only MSVC and MinGW which uses the same MSVC CRT) and so using wxGetenv() (notice the difference in case) may not return the updated value.
Parameters
var The environment variable to be set, must not contain '=' character.
value New value of the variable.
Returns
true on success or false if changing the value failed.
See Also
wxUnsetEnv()
Include file:
#include <wx/utils.h>
But I do not quite understand this description.
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):
[[ print("*line 1*\r\n*line 2*"); ]]
CodeBlocks 8500 prints the following:
While 8248 and previous correctly printed
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
The bad thing is: if I rebuild C::B, I will sometimes see the warning message(see below)
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2012-11-03215542.png)
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:
@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. :)