Author Topic: Codeblocks portable  (Read 25888 times)

Offline xors3d

  • Single posting newcomer
  • *
  • Posts: 7
Codeblocks portable
« on: October 06, 2010, 06:40:40 pm »
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?

Offline seb_seb0

  • Almost regular
  • **
  • Posts: 166
Re: Codeblocks portable
« Reply #1 on: October 06, 2010, 08:53:20 pm »
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]

Offline xors3d

  • Single posting newcomer
  • *
  • Posts: 7
Re: Codeblocks portable
« Reply #2 on: October 07, 2010, 05:16:16 pm »
can you send me your portable version?

Offline seb_seb0

  • Almost regular
  • **
  • Posts: 166
Re: Codeblocks portable
« Reply #3 on: October 07, 2010, 09:00:13 pm »
This is a normal nightly build.
You can download it in the dedicated thread.

Offline xors3d

  • Single posting newcomer
  • *
  • Posts: 7
Re: Codeblocks portable
« Reply #4 on: October 07, 2010, 09:06:47 pm »
i know....but i ask for you personal configuated portable...
perhaps if its okay for you...can i have it?

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Codeblocks portable
« Reply #5 on: October 07, 2010, 09:13:05 pm »
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.

Offline seb_seb0

  • Almost regular
  • **
  • Posts: 166
Re: Codeblocks portable
« Reply #6 on: October 07, 2010, 09:35:36 pm »
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.

Offline xors3d

  • Single posting newcomer
  • *
  • Posts: 7
Re: Codeblocks portable
« Reply #7 on: October 07, 2010, 10:24:38 pm »
ah i understand...try it...thank you

nicho211

  • Guest
Re: Codeblocks portable
« Reply #8 on: October 13, 2010, 09:29:21 am »
The portable version will help me to work everywhere. I will try to create my own version.

Offline imianz

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Codeblocks portable
« Reply #9 on: October 03, 2011, 03:11:13 pm »
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.
« Last Edit: October 03, 2011, 03:46:14 pm by imianz »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Codeblocks portable
« Reply #10 on: October 03, 2011, 04:07:58 pm »
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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline imianz

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Codeblocks portable
« Reply #11 on: October 03, 2011, 06:06:42 pm »
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.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Codeblocks portable
« Reply #12 on: October 05, 2011, 11:23:05 am »
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.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline imianz

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Codeblocks portable
« Reply #13 on: October 05, 2011, 01:28:58 pm »
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.
« Last Edit: October 05, 2011, 03:06:43 pm by imianz »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Codeblocks portable
« Reply #14 on: October 05, 2011, 01:56:19 pm »
Look at the second log, you see:
Quote
AddCompilerPredefinedMacros failed!
This mostly means that CC failed find/run the gcc compiler line.
It looks like a bug, I will check it.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline imianz

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Codeblocks portable
« Reply #15 on: October 05, 2011, 02:03:16 pm »
Well, thanks...

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Codeblocks portable
« Reply #16 on: October 05, 2011, 02:18:56 pm »
Code
Compiler relative path: $(CODEBLOCKS)\MinGW

This is the problem, the CC doesn't do macro replacements, it seems...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline imianz

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Codeblocks portable
« Reply #17 on: October 05, 2011, 02:27:04 pm »
ok, do you believe that you can fix it?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Codeblocks portable
« Reply #18 on: October 05, 2011, 02:28:45 pm »
Code
Compiler relative path: $(CODEBLOCKS)\MinGW
This is not the log message. :D :D

Quote
This is the problem, the CC doesn't do macro replacements, it seems...
True.

@imianz
You'd better post your log message in the code/quote tab.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Codeblocks portable
« Reply #19 on: October 05, 2011, 03:59:29 pm »
Code
Index: E:/code/cb/cb_trunk/src/plugins/codecompletion/nativeparser.cpp
===================================================================
--- E:/code/cb/cb_trunk/src/plugins/codecompletion/nativeparser.cpp (revision 7475)
+++ E:/code/cb/cb_trunk/src/plugins/codecompletion/nativeparser.cpp (working copy)
@@ -663,7 +663,9 @@
             if (compiler->GetID().Contains(_T("gcc")))
             {
                 wxFileName fn(wxEmptyString, compiler->GetPrograms().CPP);
-                fn.SetPath(compiler->GetMasterPath());
+                wxString masterPath = compiler->GetMasterPath();
+                Manager::Get()->GetMacrosManager()->ReplaceMacros(masterPath);
+                fn.SetPath(masterPath);
                 fn.AppendDir(_T("bin"));
                 const wxArrayString& gccDirs = GetGCCCompilerDirs(fn.GetFullPath());
                 TRACE(_T("Adding %d cached gcc dirs to parser..."), gccDirs.GetCount());
@@ -792,7 +794,9 @@
         if (CompilerID.Contains(_T("gcc")))
         {
             wxFileName fn(wxEmptyString, ((Compilers[idxCompiler])->GetPrograms()).CPP);
-            fn.SetPath((Compilers[idxCompiler])->GetMasterPath());
+            wxString masterPath = (Compilers[idxCompiler])->GetMasterPath();
+            Manager::Get()->GetMacrosManager()->ReplaceMacros(masterPath);
+            fn.SetPath(masterPath);
             fn.AppendDir(_T("bin"));
             const wxArrayString& gccDirs = GetGCCCompilerDirs(fn.GetFullPath());
             TRACE(_T("Adding %d cached gcc dirs to parser..."), gccDirs.GetCount());
@@ -837,7 +841,9 @@
             return false;
 
         wxFileName fn(wxEmptyString, compiler->GetPrograms().CPP);
-        fn.SetPath(compiler->GetMasterPath());
+        wxString masterPath = compiler->GetMasterPath();
+        Manager::Get()->GetMacrosManager()->ReplaceMacros(masterPath);
+        fn.SetPath(masterPath);
         fn.AppendDir(_T("bin"));
 
         static std::map<wxString, wxString> defsMap;
@@ -917,7 +923,10 @@
             Compiler* compiler = CompilerFactory::GetCompiler(compilerId);
             if(!compiler)
                 return false;
-            wxString cmd = compiler->GetMasterPath() + _T("\\bin\\") + compiler->GetPrograms().C;
+
+            wxString masterPath = compiler->GetMasterPath();
+            Manager::Get()->GetMacrosManager()->ReplaceMacros(masterPath);
+            wxString cmd = masterPath + _T("\\bin\\") + compiler->GetPrograms().C;
             Manager::Get()->GetMacrosManager()->ReplaceMacros(cmd);
 
             // wxExecute can be a long action and C::B might have been shutdown in the meantime...
The patch should fix the problem, but do we need to refactor the function body GetMasterPath()?
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline imianz

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Codeblocks portable
« Reply #20 on: October 05, 2011, 11:14:24 pm »
The patch should fix the problem, ....

Yeah! It does.
I can confirm you.
I was too curious to wait for the patch was placed in a nightly build, so I downloaded the source code (7478) and manually applied the patch and build...
Not tested hard, but at first glance seems to work ok.

Post scriptum
The strange thing is the CB splash screen, it show me the revision zero... mah!

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Codeblocks portable
« Reply #21 on: October 05, 2011, 11:16:40 pm »
The strange thing is the CB splash screen, it show me the revision zero... mah!
It is normal, you have to run some script to generate the info...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Codeblocks portable
« Reply #22 on: October 06, 2011, 12:25:14 am »
The strange thing is the CB splash screen, it show me the revision zero... mah!
It is normal, you have to run some script to generate the info...
On windows you need commandline svn in systempath in addition to a gui-client like TortoiseSVN.

Offline imianz

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Codeblocks portable
« Reply #23 on: October 06, 2011, 07:10:59 pm »
Thank you guys!