Author Topic: Can I make C::B portable?  (Read 39763 times)

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: Can I make C::B portable?
« Reply #30 on: January 02, 2007, 02:23:24 am »
Hi.
I've tested the steps with cb_20070101_rev3446_win32 and borland's bcc55.

I extracted the file, started cb and wanted to disable DragScroll and Keyboard shortcuts plugin. After a click on disable button codeblocks crashs. Then i started it again and this time i could disable it. The same with the other plugin.

After that i copied content of %appdata%\codeblocks\ to my codeblocks folder and configured relative paths by using $(codeblocks). Now i have running a portable version.  :D

Just want you to inform about the crash and give a little summary.



With this patch [ Patch #1783 ] , you should not have to disable keyboard shortcuts (keybinder) or DragScroll. It fixes the config .conf location problem, allowing the plugins to store their setting in your "portable" .conf location.

Thanks to Tim S
 
« Last Edit: January 02, 2007, 02:25:12 am by Pecan »

code2008

  • Guest
Re: Can I make C::B portable? .. making codeblocks "portable"
« Reply #31 on: April 02, 2007, 11:21:51 am »
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.
« Last Edit: April 02, 2007, 11:27:03 am by code2008 »