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?
I put a relative path to Mingw using variables in Codeblocks
Example: for the toolchain path, I use
$(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]
can you send me your portable version?
This is a normal nightly build.
You can download it in the dedicated thread.
i know....but i ask for you personal configuated portable...
perhaps if its okay for you...can i have it?
If it's true, what you write:
Quote from: xors3d on October 06, 2010, 06:40:40 PM
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.
Quote from: xors3d 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?
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:
<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.
ah i understand...try it...thank you
The portable version will help me to work everywhere. I will try to create my own version.
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.
Quote from: imianz on October 03, 2011, 03:11:13 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.
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.
Quote from: imianz on October 03, 2011, 06:06:42 PM
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
--debug-log2, so that there will be a debug log tab, you can see the image here: 8.1 Debug Log output (http://wiki.codeblocks.org/index.php?title=Code_Completion_Design#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.
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
...
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
...
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.
Look at the second log, you see:
QuoteAddCompilerPredefinedMacros failed!
This mostly means that CC failed find/run the gcc compiler line.
It looks like a bug, I will check it.
Well, thanks...
Compiler relative path: $(CODEBLOCKS)\MinGW
This is the problem, the CC doesn't do macro replacements, it seems...
ok, do you believe that you can fix it?
Quote from: oBFusCATed on October 05, 2011, 02:18:56 PM
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.
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()?
Quote from: ollydbg on October 05, 2011, 03:59:29 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!
Quote from: imianz on October 05, 2011, 11:14:24 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...
Quote from: oBFusCATed on October 05, 2011, 11:16:40 PM
Quote from: imianz on October 05, 2011, 11:14:24 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...
On windows you need commandline svn in systempath in addition to a gui-client like TortoiseSVN.
Thank you guys!