User forums > Using Code::Blocks

Relative path in output build?

<< < (2/2)

gerardpuducul:
fiinally I found a solution!  :P 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 $<)

Navigation

[0] Message Index

[*] Previous page