As usual:Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo.Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc16, fc17 and fc18) can be found in my rpm-repo .Packages for CentOS/RedHat 5 and 6 will follow. can be found there too.

Target is up to date.[100.0%] Running target pre-build stepsbuild_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.

So, I suspect the PATH variable was sometimes changed by compiler plugin? I will check an old nightly build version.

Logged

If some piece of memory should be reused, turn them to variables (or const variables).If some piece of operations should be reused, turn them to functions.If they happened together, then turn them to classes.

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?

Logged

If some piece of memory should be reused, turn them to variables (or const variables).If some piece of operations should be reused, turn them to functions.If they happened together, then turn them to classes.

...then (and only then!), all my low-level code that relies on envvars being set worked properly. You may face a similar issue here.

Logged

If some piece of memory should be reused, turn them to variables (or const variables).If some piece of operations should be reused, turn them to functions.If they happened together, then turn them to classes.

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.

« Last Edit: November 04, 2012, 11:57:20 am by ollydbg »

Logged

If some piece of memory should be reused, turn them to variables (or const variables).If some piece of operations should be reused, turn them to functions.If they happened together, then turn them to classes.

So - according this its OK. And yes, of course I know its a variable and not a constant. I thought oBFusCATed meant the length() method not being standard and I wanted to point put that it returns a const size_t.