Codeblocks portable

[xors3d]

Have finished the codeblocks portable...
only installed on stick...insert mingw in the codeblocks directory....and using a simple .bat...

but one problem exist...the default.conf....
everey time i use the portable version i have to delete the default.conf file because in there are absolute path for mingw.
have anyone a solution for this...
have try to change the absolute path to /mingw....
but seems not to work correctly...

can anybody help me?

[seb_seb0]

I put a relative path to Mingw using variables in Codeblocks
Example: for the toolchain path, I use

Code

$(Codeblocks)\..\..\BIN\MingW_TDM

(see screenshot)

It works fine for everything: toolchain (Mingw, mingw TDM, MSVC, Help plugin, tool plugin)

In addition, I use the CBLauncher from biplap (search the forums).
I save all my config in $(Codeblocks)\AppData (delete every other conf files you may find on your system: in CB directory, in C:\Users\<user>\AppData\Roaming\codeblocks (Windows Vista), ...)

And I use a bat file to set the path to other utilities, such as CMake or Doxygen. (The .bat sets the PATH variable, and then launch CBLauncher).

This way, I have CodeBlocks + 2 compilers + Libraries + additional tools inside 1 folder that I move around. The path can have spaces in it.
At work, this folder stays on my desktop.

Hope this helps.

Sebastien
 

[attachment deleted by admin]

[xors3d]

can you send me your portable version?

[seb_seb0]

This is a normal nightly build.
You can download it in the dedicated thread.

[xors3d]

i know....but i ask for you personal configuated portable...
perhaps if its okay for you...can i have it?

[Jenna]

If it's true, what you write:

but one problem exist...the default.conf....
everey time i use the portable version i have to delete the default.conf file because in there are absolute path for mingw.

You can use $(CODEBLOCKS) variable in compilers installation path (in Toolchain executables).
The $(CODEBLOCKS) variable always points to the directory the running C::B resides in.
So you can get rid of the absolute paths.

[seb_seb0]

i know....but i ask for you personal configuated portable...
perhaps if its okay for you...can i have it?

This is what I told you: this is NOT a specific build of Code::Blocks.
The only thing I do is to use the $(CodeBlocks) variable everywhere in my settings. (compiler toolchain, help files, tools, global variables)
Just try it !

I know it is working for :
  - Mingw, Mingw TDM, MSVC09
  - with spaces in the installation path ("Documents and Settings\UserName\Desktop\" for example)
  - installation on another drive (D:\)

If you have full path in your default.conf, then it means you are using full paths in your settings. You have to find the correct options.
I have checked my default.conf, and I have no full path in it. See for example:

Code

<MASTER_PATH>
	<str>
		<![CDATA[$(Codeblocks)\..\..\BIN\MingW_TDM]]>
	</str>
</MASTER_PATH>

So just try to use the $(CodeBlocks) variable: Set your options, QUIT codeblocks (to save the file) and start it again.

[xors3d]

ah i understand...try it...thank you

[nicho211]

The portable version will help me to work everywhere. I will try to create my own version.

[imianz]

Hi all,
I need some help around the use of environment variables to make codeblocks paths relative (for portable/stand alone purpose) under windows. I have find some difference from stable 10.05 release and the recent nightly builds v7385.
Eg. changing compiler path from absolute to relative as follow

Settings -> Compiler and debugger -> Global compiler -> GNU GCC Compiler -> Toolchain executables:
$(CODEBLOCKS)/MinGW
or
%MY_OWN_ENV%/MinGW

compiler and other things seems to works fine, but in the nightly builds some features stops to work:
autocompletion fails in some cases (eg. windows api function name from windows.h) and I'm not able to open MinGW include files (right click contest menu: open #include file: 'winsock.h') but only local project files.
What is changed? Is there another way to works around this problem?

Thanks in advance.

[ollydbg]

compiler and other things seems to works fine, but in the nightly builds some features stops to work:
autocompletion fails in some cases (eg. windows api function name from windows.h) and I'm not able to open MinGW include files (right click contest menu: open #include file: 'winsock.h') but only local project files.
What is changed? Is there another way to works around this problem?

This is nothing to do with the c::b portable.
Can you give us a simple test code and tell us how to show such error.
BTW: codecompletion plugin has a lot of code changes since the 10.05 version.

[imianz]

ok, now I try to explain better.
I'm using some different copy of codeblocks ide at the same time, each with a different version of mingw.
Something like this:

C:\Dev\Codeblocks_802NB_v6088
C:\Dev\Codeblocks_1005
C:\Dev\Codeblocks_1005x64
C:\Dev\Codeblocks_1005NB_v7385

To make this possible I have developped a simple launcher that start codeblocks.exe and set an "AppData" folder locally for any of the above etc etc.... nothing special.
Finally, for each environment, I have to manually set the compiler path as "relative":
Settings -> Compiler and debugger -> Global compiler -> GNU GCC Compiler -> Toolchain executables
%MYCBPATH%\MinGW
or
$(CODEBLOCKS)\MinGW

Everything has worked well, but recently I downloaded the NB v7385.
For example, using a relative compiler path, I noticed these two problems:

1. when write "SetWind" in the editor does not appear the autocompletion list showing SetWindowsText, SetWindowPos, etc...
2. Using "open #include file" feature (eg. right click over "#include <windows.h>") fails and returning the following error message: "Not found: windows.h".


Setting a valid "absolute" compiler path everithing works well again.

[ollydbg]

Setting a valid "absolute" compiler path everithing works well again.

Ok, it should be a bug, but I'm not sure how the compiler path is correctly handled in CC. Can you test this:

1, start the codeblocks portable with extra command line option

Code

--debug-log

2, so that there will  be a debug log tab, you can see the image here: 8.1 Debug Log output

3, then when you open a project, the CC will try to find the compiler's default search paths, and log out, you can paste the log here, I guess that the default search include paths was not correct in your case.

4, compare the result of 3 if you use the absolute path of the compiler path.

[imianz]

ok, I pasted below two logs taken from the debug window.
I have omitted, in both cases, the first 170 lines, because identical and, imho, not very interesting.


Compiler absolute path: I:\CB1005NB\MinGW

Code

...
Done loading project in 47ms
Project's base path: I:\_Prj\Test\
Project's common toplevel path: I:\_Prj\Test\
Text seems to be pure ASCII!
We use user specified encoding: Windows Western European (CP 1252) (ID: 33)
Final encoding detected: Windows Western European (CP 1252) (ID: 33)
Editor Open
project data set for I:\_Prj\Test\main.cpp
Top Editor: I:\_Prj\Test\main.cpp
Caching GCC dir: I:\CB1005NB\MinGW\lib\gcc\mingw32\4.5.2\include\c++
Caching GCC dir: I:\CB1005NB\MinGW\lib\gcc\mingw32\4.5.2\include\c++\mingw32
Caching GCC dir: I:\CB1005NB\MinGW\lib\gcc\mingw32\4.5.2\include\c++\backward
Caching GCC dir: I:\CB1005NB\MinGW\include
Caching GCC dir: I:\CB1005NB\MinGW\lib\gcc\mingw32\4.5.2\include
Caching GCC dir: I:\CB1005NB\MinGW\lib\gcc\mingw32\4.5.2\include-fixed
Passing list of files to batch-parser.
Header to parse with priority: 'I:\CB1005NB\MinGW\lib\gcc\mingw32\4.5.2\include\c++\cstddef'
Header to parse with priority: 'I:\CB1005NB\MinGW\include\w32api.h'
Add 2 priority parsing file(s) for project 'TestPrj'...
Added 2 file(s) for project 'TestPrj' to batch-parser...
Create new parser for project 'TestPrj'
Starting batch parsing for project 'TestPrj'...
Project 'TestPrj' parsing stage done!
Project 'TestPrj' parsing stage done (26 total parsed files, 16297 tokens in 0 minute(s), 1.156 seconds).
Updating class browser...
Class browser updated.

Compiler relative path: $(CODEBLOCKS)\MinGW

Code

...
Done loading project in 31ms
Project's base path: I:\_Prj\Test\
Project's common toplevel path: I:\_Prj\Test\
Text seems to be pure ASCII!
We use user specified encoding: Windows Western European (CP 1252) (ID: 33)
Final encoding detected: Windows Western European (CP 1252) (ID: 33)
Editor Open
project data set for I:\_Prj\Test\main.cpp
Top Editor: I:\_Prj\Test\main.cpp
AddCompilerPredefinedMacros failed!
Passing list of files to batch-parser.
Added 2 file(s) for project 'TestPrj' to batch-parser...
Create new parser for project 'TestPrj'
Starting batch parsing for project 'TestPrj'...
Project 'TestPrj' parsing stage done!
Project 'TestPrj' parsing stage done (3 total parsed files, 21 tokens in 0 minute(s), 0.016 seconds).
Updating class browser...
Class browser updated.

[ollydbg]

Look at the second log, you see:

AddCompilerPredefinedMacros failed!

This mostly means that CC failed find/run the gcc compiler line.
It looks like a bug, I will check it.