User forums > Using Code::Blocks

Codeblocks portable

<< < (3/5) > >>

ollydbg:

--- 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?

--- End quote ---
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:

--- Quote from: imianz on October 03, 2011, 06:06:42 pm ---Setting a valid "absolute" compiler path everithing works well again.

--- End quote ---
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
--- End code ---

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.

--- End code ---


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.

--- End code ---

ollydbg:
Look at the second log, you see:

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page