I have noticed that, under Windows, C::B would respect a default.conf file in .../Application Data/codeblocks/ even if one has such a file in the base C::B directory. This seems to me like an erroneous behaviour, as it is then not possible to have a portable or copiable, i.e. self-contained, version of C::B, like the one suggested near the end of 1.10.4 of the User Manual.
C::B supports portable usage on Windows, search the forum for Portable.
Quote from: boykobb on November 15, 2011, 04:23:36 PM
I have noticed that, under Windows, C::B would respect a default.conf file in .../Application Data/codeblocks/ even if one has such a file in the base C::B directory. This seems to me like an erroneous behaviour, as it is then not possible to have a portable or copiable, i.e. self-contained, version of C::B, like the one suggested near the end of 1.10.4 of the User Manual.
If both configuration files are present, that's the expected behaviour.
Quote from: oBFusCATed on November 15, 2011, 04:47:13 PM
C::B supports portable usage on Windows, search the forum for Portable.
I did search, but I couldn't find what I need.
What I would like is a C::B that could be copied all to a single (any) folder, along with its own default.conf in the same folder, and independent of .conf files that may be residing elsewhere. Is that possible to do? Thanks.
Have you read this whole topic: http://forums.next.codeblocks.org/index.php/topic,10360.0.html ?
Quote from: oBFusCATed on November 15, 2011, 08:21:46 PM
Have you read this whole topic: http://forums.next.codeblocks.org/index.php/topic,10360.0.html ?
Yes – and it was all useless to me.
What is being discussed there is a separate program that:
• one
must use to launch C::B instead of launching C::B directly;
• is not part of C::B, and (as I understand it) is not guaranteed to work with future versions of it;
• does things I am not sure of what they are, and I cannot observe or change;
• probably still contains bugs (we don't know).
In fact, there is a much better solution for what that launcher does: launching C::B with a non-default personality. A .bat or .lnk file would suffice to implement this. Unfortunately, one can still not guarantee that C::B can
only be launched that way.
A cleaner solution would not need to rely on conventions, just on (pre)configuration of C::B.
If you are fine with the way PortableApps.com applications work, you could try Code::Blocks Portable (http://portableapps.com/node/18671). It is still a development test (and possibly abandoned??), however, if you make the one change mentioned in the comments, it works perfectly fine (you can even replace the internal Code::Blocks with an SVN build).