These instructions are for the codeblocks nightly builds. A previous post in this thread has suggested that in RC2 they use the windows registry:
http://forums.codeblocks.org/index.php/topic,4475.msg35370.html#msg35370>There should be no reason why that should not work. The development version of Code::Blocks should be alltogether relocatable ("portable").
>For RC2/Windows, that's of course not true, since RC2 writes its configuration to the Windows registry.
For the codeblocks nightly builds:
To install:
http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_nightly_build_on_Windows mingw and gdb
download nightly
mingwm10.dllf
wxmsw26u_gcc_cb.dll
using 7zip to extract the .7z files, put them in the same directory, so you will have:
bin/
...
codeblocks.exe
...
mingwm10.dll
wxmsw26u_gcc_cb.dll
If the directories overlap, that is fine. If some file is being overwritten by an older version, maybe you can keep the newer version (not recall if this happened).
You can now run "codeblocks.exe". This so far is the usual way to run a nightly build.
However, to make it portable (runnable from a portable hard disk, usb flash drive) - to make sure it writes to a local version of the settings files - you need to copy the following "run_codeblocks.bat" (windows batch) file to this directory as well. You can copy and paste the text below into a text file and save it somewhere. Then after a new nightly build has been setup, you can just copy this .bat file into the same directory and make sure you run using that "run_codeblocks.bat" instead of "codeblocks.exe". The settings files (default.conf etc.) will now be saved-to/read-from a local directory "settings\Application Data\codeblocks\".
The reason this works is that codeblocks seems to look at the windows environment variable USERPROFILE. If you change that before you run codeblocks.exe, you can point it to a local version. The batch file sets up the changed USERPROFILE, runs codeblock.exe, and then exits itself, while codeblocks.exe remains running.
NOTE: as a clarification, this DOES NOT change the USERPROFILE for any other program or for windows in general, but ONLY for the program spawned by "run_codeblocks.bat". So you need not be worried about the impact of changing a windows environment variable, as that impact is confined to (only seen by) programs spawned in the batch file i.e. codeblocks.exe and any programs that codeblocks.exe spawns (compilers etc.).
Now when you run "run_codeblocks.bat", the settings files will be saved in local directory "settings/Application Data/codeblocks/" that will contain the files created/saved/read by codeblocks:
share/
cbKeyBinder10.ini
codesnippets.xml
default.conf
...
The file "run_codeblocks.bat" should contain:
---cut here---
rem change windows environment variable USERPROFILE to point to local directory "settings"
set USERPROFILE=%~dp0settings
rem create the directory structure (in the local directory) that codeblocks will now require
rem (now that you have pointed USERPROFILE to that directory)
mkdir %USERPROFILE%
rem windows requires use of quotes here because of space in directory name
mkdir %USERPROFILE%\"Application Data"
rem for help on START, type "START /?" in windows command window (Run "cmd.exe")
rem
rem %~dp0 same as batch file directory
rem %* pass on parameters that passed to this batch file to codeblocks.exe
rem
START /D"%~dp0" codeblocks.exe %*
---cut here---
This has been tested very superficially with the recent nightly build of codeblocks. The program opens/closes fine and the settings are saved/retreived correctly. However I have not done anything more with this setup.
Maybe users can report how this fares for more complicated use.
Thanks.
