Can I make C::B portable?

[Squeller]

Hi,

can I make cb portable together with the gnu gcc compiler? This requires to set relative paths e.g. in the compiler options. Has someone tried it?

Thx

[thomas]

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.

[bigbug]

Some time ago I tried it. I managed it to make the compiler directory relative by using the variable $(CODEBLOCKS). But it didn't work for the debugger. It looked like the builtin variables weren't expanded for the invocation of the debugger.

[Pecan]

Search the main index for "usb". There's a lot of info on portability.

[bigbug]

I've tried it again. It still doesn't work, because:

• if you use a relative path in "Global compiler settings/Programs", it's relative to the current project
• builtin variables neither expand if used for the "Compiler's installation directory" nor if used for the debugger path

Would it be a great effort to make the builtin variables expand in either the "Compiler's installation directory" or the debugger path?

[thomas]

Proof of concept:

Compiling Code::Blocks svn sources (located on drive D:) with Code::Blocks revision 3222 and MinGW 3.4.5, both located on a USB stick (drive G:), using preferences stored on the same USB stick.

[bigbug]

If you have a MinGW installation (e.g. in C:\MinGW), did you try renaming the folder? I tried and if I don't rename it, Code::Blocks automagically uses the compiler from my local MinGW but if I rename it, Code::Blocks says:
Execution of 'mingw32-g++.exe ...' failed.

Edit:
Looking at your "File Monitor" screenshot, it seems Code::Blocks opens "G:\CodeBlocks\mingw32-g++.exe". Since your Code::Blocks executable is located at "G:\CodeBlocks\codeblocks.exe" and your compiler directory is "$(codeblocks)\..\mingw", shouldn't it open "G:\mingw\bin\mingw32-g++.exe"?

[thomas]

If it fails for you, it may depend on the path, as the compiler plugin works on that. Mandrav is looking into it right now.
Probably a one-liner

[mandrav]

If it fails for you, it may depend on the path, as the compiler plugin works on that. Mandrav is looking into it right now.
Probably a one-liner

An one-liner it was, bug fixed.

[bigbug]

Thank You!!!

[Squeller]

Thanks anyone for your information, I think I'll get it working next week when I have time.

[Belgabor]

One small thing to add: Global variables (a la $(#mingw)) don't seem to work for the "Compiler's install directory".

[Squeller]

OK, I've put my mingw directory to the codeblocks directory and put the $(codeblocks) variable to the compiler options, which seems to work.

But a stupid questions: Where does c::b store it's settings?

[thomas]

OK, I've put my mingw directory to the codeblocks directory and put the $(codeblocks) variable to the compiler options, which seems to work.

But a stupid questions: Where does c::b store it's settings?

In a folder codeblocks inside your "Application Data" folder (usually in C:\Documents and Settings\...).
However, to make Code::Blocks "portable", you just copy the profile you want to the folder where Code::Blocks lives, that one has precedence. This way, you can put it onto a memory stick or cdrom, or whatever.

[Squeller]

Thanks, very good design.
I've simply overseen the codeblocks folder in %appdata%.

[Squeller]

OK, I've put the contents of %appdata%\codeblocks\ into my codeblocks directory. Those are:

Code

cbKeyBinder04v110.ini
cbKeyBinder04v19.ini
cbKeyBinder10v111.ini
cbKeyBinder10v111.ini.bak
codesnippets.xml
default.conf
DragScroll.ini

...and a "share" folder with subfolders which are all empty. After deletion of the %appdata%\codeblocks\share\ folder and any startup of c::b, I get the error message:

"Can not enumerate files in directory U:\Dokumente und Einstellungen\User\Anwendungsdaten\codeblocks\share/codeblocks/plugins (error 3: System can't find path)"

Why does it want that empty directory?

Also, if finding all necessary config files in $(codeblocks) dir, why does it create these under %appdata% again? (Though they also appear in the codeblocks directory)?

Code

share\ (it creates this dir again, but not the plugins subfolder)
cbKeyBinder10v111.ini
codesnippets.xml

[darus]

I can't make it work too.

When I create an empty default.conf in CB folder and run CB, it pops an exception dialog:

Code

The application encountered an error at sdk\configmanager.cpp, on line 131.
The error message is:

TinyXML error: Error document empty.
In file: default.conf
At row 0, column 0.

Code::Blocks Version revision 3240 (gcc 3.4.5, build: Nov 16 2006 23:32:14)

[tiwag]

I can't make it work too.
When I create an empty default.conf in CB folder and run CB, it pops an exception dialog:

you should copy an already created an valid config file there

[thomas]

...and a "share" folder with subfolders which are all empty. After deletion of the %appdata%\codeblocks\share\ folder and any startup of c::b, I get the error message

Also, if finding all necessary config files in $(codeblocks) dir, why does it create these under %appdata% again? (Though they also appear in the codeblocks directory)?

Because "user plugins" were added a long time after everything else, and because the person adding them was not the same as the person writing the other path handling functions. Such things happen.
Because nobody ever uses the relocation feature, we don't see the error, and we don't get feedback on it (until now). Therefore, things like that may go unnoticed. Even if we use the feature (as I did a few days ago), the problem doesn't show up on developers' machines either, as we do have those folders in our profile folders.

cbKeyBinder10v111.ini
codesnippets.xml

Those are not strictly Code::Blocks, these belong to contrib plugins. Quite likely, they suffer from the same problem as the "empty folder" one, though.

[thomas]

All those issues should be fixed now. I've tried launching Code::Blocks with no config at all, re-launch it in "normal" mode, and relaunch it in "relocated" mode, removing all installed files from the PC first.

[Squeller]

I've put c::b plus it's config files to a computer with no c::b on it.

1. Startup was fine.
2. Created a console application with the wizard.
3. Edited the source code.

After a couple of seconds an error message appeared:

Code

09:25:16: Failed to create a temporary file name (error 267: der Verzeichnisname ist ungültig.)
09:25:16: can't open user configuration file.

Those are my files in the codeblocks folder:

Code

cb_console_runner.exe
cbKeyBinder04v110.ini
cbKeyBinder04v19.ini
cbKeyBinder10v111.ini
cbKeyBinder10v111.ini.bak
codeblocks.dll
codeblocks.exe
codesnippets.xml
default.conf
DragScroll.ini
exchndl.dll
mingwm10.dll
wxmsw26u_gcc_cb.dll
wxscintilla.dll

EDIT: In order to make it portable, I probably have to narrow the default.conf down to only some necessary settings, including the compiler relative path...

[Squeller]

I think this is not perfect. If I copy the c::B to another computer without the default.conf, it does create on in %appdata%. If I put that one into the cb folder, I get the previously mentioned error message. So I think a) c::b cannot live without the default.conf in %appdata%\c::b, and b) I think there is some invalid (absolute?) paths saved in the .conf file.

[thomas]

I could imagine the source of this error is one of the contrib plugins, because I saw no such error when I tried with "plain vanilla" Code::Blocks and only the standard core plugins loaded.

Could you please try disabling or deleting one by one and see if the error ceases?

[Squeller]

This is a hard task, because I haven't found an easy way to reproduce the error message. It does just appear sometimes.
OK, with dragscroll.dll turned off, the error message does appear more rarely now (with dragscroll.dll turned on, it happens e.g. any time after changing an editor setting).

[Pecan]

I suspect this is caused by the merge timer in KeyBinder.
KeyBinder and Dragscroll know nothing about portable directories.

I cannot look at it until the last week of November.
Disable Dragscroll and KeyBinder to see if the problem goes away.

[Pecan]

DragScroll and KeyBinder get their conf directory with the following.

Code

    //memorize the key file name as {%HOME%}\cbKeyBinder+{vers}.ini
    m_sKeyFilename = ConfigManager::GetConfigFolder();

KeyBinder looks to merge dynamic menu keys to its .ini file every 15 seconds,
backs up the .ini to .ini.bak and writes the new merged .ini file.

I don't see the problem, but I can only test this after November.

[Squeller]

Thanks, Pecan. The timer behaviour explains, why I wasn't easily able to reproduce it. OK. I've moved all my config files to c::b dir again; looks like it's solved... I'll test more thoroughly later the day,,,

[Squeller]

Pecan, you're right. I have disabled both plugins and c::b is now fully portable without any problems afaics. I've worked 2 hrs. without a problem with it.

[stahta01]

The setup of ConfigManager::GetConfigFolder() variable ConfigManager::config_folder in the method ConfigManager::InitPaths() needs work to make it portable.

Tim S

PS: I trying to write a small patch to make ConfigManager::GetConfigFolder portable right now.

Uploaded patch
[ Patch #1783 ] GetConfigFolder patch to make it work in a Portable win32
https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=1783&group_id=5358

NOTE: If you are talking about this patch please mention Patch #1783 in the message.

[stretchboom]

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. 

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

[Pecan]

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. 

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
 

[code2008]

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.