Relative path in output build?

[gerardpuducul]

Hy all,

My compiler is a GNU AMR GCC. In is build output, he send me back relative path from the working directory for error and warning. I have modified my parser rule to retrieve the file, line, message information. But when I click on the highlited error in the build log (or build message) nothing happen.

Is codeblock support relative path output debug? Is there a way to support it?


Thanks

for example here is on of my error :

"..\..\source\th_rf.c", line 487: Serious error: C2291E: <expression> expected but found '/'

with my parser rule  :

Code

 (")(.*)("),( line) ([0-9]+):( Error:[ \t].*)

I have
filename : ..\..\source\th_rf.c
line number : 487
Message : Serious error

[MortenMacFly]

with my parser rule  :

Code

 (")(.*)("),( line) ([0-9]+):( Error:[ \t].*)

What about :

Code

 (")(.*)("),( line) ([0-9]+):( [Ee]rror:[ \t].*)

[gerardpuducul]

Yes of course there is a litlle mistake with my parser rule but this not solve my problem. The parse seems to be done correctly but when i click on the highlited build message nothing happen. Codeblock don't focus on the corrresponding file at the corresponding line (in fact it does nothing). This is why i ask if codeblock support relative path.


Anyway thank for your answer!

Do you have an explaination about this behaviour? can codeblock work with relative path?

thanks

[Jenna]

Jumping to relative filenames work for me.

Try this expression:

Code

"(.*)", line ([0-9]+): (.*)

and set Message to 3, Filename to 1 and line to 2.

That works for me with your error line:

Code

Regular expression analyzed as follows:

Type: Error message
Filename: ../../source/th_rf.c
Line number: 487
Message: Serious error: C2291E: <expression> expected but found '/'

[gerardpuducul]

Thanks your parse rule work better that mine (the message error is now complete). But this not solve my problem anymore.

Maybe due to my special configuration. I use a custom makefile and i launch the make process from a special directory :

Code

make -C C:\test\toto

Is it the possible?

thanks

[gerardpuducul]

fiinally I found a solution!  I must change the projet directory to my custom makefile directory and now codeblock jump to the parse information! good!

but is it normal?

why codeblock use my project  directory for working directory instead of my custom makefile directory ?

Is there a way to do that? (I have try to change the execution working directory but it doen't seem to do something  )

thanks!!!!

[mingkoonkat]

FWIW, we also use a custom makefile system for the EPICS project which generates relative paths (with "./a/b/../c.c" in them), and so far I haven’t managed to work out how configure this IDE so that one can click on the error messages in order to vector the focus to the appropriate source file line. I did try locating the project directory where the custom makefile resides, as the previous posts suggest, with no success. I use code block 12.11 from Jan 10th.

../CASG.cpp||In member function ‘void CASG::destroyCompletedIO(CallbackGuard&, epicsGuard<epicsMutex>&)’:|
../CASG.cpp|151|error: no matching function for call to ‘syncGroupNotify::destroy(CallbackGuard&, epicsGuard<epicsMutex>&, CASG&)’|
../CASG.cpp|151|note: candidate is:|
../syncGroup.h|65|note: virtual void syncGroupNotify::destroy(epicsGuard<epicsMutex>&, casgRecycle&)|
../syncGroup.h|65|note:   candidate expects 2 arguments, 3 provided|
../CASG.cpp||In member function ‘void CASG::destroyPendingIO(CallbackGuard&, epicsGuard<epicsMutex>&)’:|
../CASG.cpp|161|error: no matching function for call to ‘syncGroupNotify::cancel(epicsGuard<epicsMutex>&)’|
../CASG.cpp|161|note: candidate is:|
../syncGroup.h|70|note: virtual void syncGroupNotify::cancel(CallbackGuard&, epicsGuard<epicsMutex>&)|
../syncGroup.h|70|note:   candidate expects 2 arguments, 1 provided|
../CASG.cpp||In member function ‘bool CASG::ioComplete(epicsGuard<epicsMutex>&)’:|
../CASG.cpp|209|error: no matching function for call to ‘CASG::destroyCompletedIO(epicsGuard<epicsMutex>&)’|
../CASG.cpp|209|note: candidate is:|
../CASG.cpp|144|note: void CASG::destroyCompletedIO(CallbackGuard&, epicsGuard<epicsMutex>&)|
../CASG.cpp|144|note:   candidate expects 2 arguments, 1 provided|
||=== Build finished: 3 errors, 0 warnings (0 minutes, 1 seconds) ===|

[mingkoonkat]

OK, so when actually looking at the compiler output maybe its quite hard for C::B to deal with this issue (sorry).

Perhaps instead gcc could easily provide an option to output full paths in its diagnostic messages, even if relative paths are on its command line; unfortunately It appears that it doesn’t currently provide such an option.

Or we could amend our build system as suggested in this post.

http://gcc.gnu.org/ml/gcc-help/2008-03/msg00084.html

[mingkoonkat]

 For completeness, in a gnu make based build system this fix works fine BTW (sorry this is rapidly diverging off topic).

%$(OBJ): %.c
    @$(RM) $@
-   $(COMPILE.c) -c $<
+   $(COMPILE.c) -c $(realpath $<)
 
 %$(OBJ): %.cc
    @$(RM) $@
-   $(COMPILE.cpp) -c $<
+   $(COMPILE.cpp) -c $(realpath $<)
 
 %$(OBJ): %.cpp
    @$(RM) $@
-   $(COMPILE.cpp) -c $<
+   $(COMPILE.cpp) -c $(realpath $<)