Passing command line options to compiler

[JasperC]

Hello all,

I'm a new to using Code::Blocks, so far I've been using gedit and the command line to compile my programs.  I'd like to move to CB, but I've run into a problem.  I'm running CB 10.05 on Ubuntu 11.04 x32, and my code makes use of ROOT.  To compile, I've been using the following at the Terminal:

Code Select Expand

g++ mycode.c `root-config --cflags --libs`

I'm currently stuck trying to pass that last bit to the compiler when using CB.  I've read this, and under

Project -> Build options... -> [Project name] -> [GNU GCC Compiler] -> Compiler settings -> Other options, and
Project -> Build options... -> [Project name] -> [GNU GCC Compiler] -> Linker settings -> Other linker options

I have added in

Code Select Expand

`root-config --cflags --libs`

However when I build the project, the build log shows that that arguement is not passed to g++.


Project -> Build options... -> [Project name] -> [GNU GCC Compiler] -> Compiler settings -> Other options
does have a "-fexceptions" already added, and that does get passed, so I'm not sure what could be wrong.  Advice would be appreciated, thanks!

[Jenna]

The argument between the backticks will be expanded and the result is put into the commandline.
If you turn on full commandline logging ( http://wiki.codeblocks.org/index.php?title=FAQ-Compiling_%28errors%29#Q:_How_do_I_troubleshoot_an_compiler_problem.3F ) , you should be able to see it.

[JasperC]

Hi Jens,

Thanks for the reply.  Guess I wasn't that clear in my post, but I have read the FAQ and already turned on full commandline logging.  The problem is the backticks(?) argument does not appear in the commandline, either expanded or unexpanded.

There is already a "-fexceptions" option specified, and I can remove and restore that with the expected result.  My argument seems to be ignored however...

[stahta01]

When you run the following on a command line, what is the result?

Code Select Expand


root-config --cflags --libs


[JasperC]

When you run the following on a command line, what is the result?

Code Select Expand


root-config --cflags --libs


I get

Code Select Expand


-pthread -m32 -I/home/jasper/gate/root_5.28.00e/include -L/home/jasper/gate/root_5.28.00e/lib -lCore -lCint -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lTree -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -pthread -lm -ldl -rdynamic


So I know that part of it should work at least...

[Jenna]

If you start C::B from a console with the -d parameter:

Code Select Expand

codeblocks -d
you should have an additional tab in "Logs & others" called "Code::Blocks Debug".

After opening your project you can onspect it and see, whether there is an entry like:

Code Select Expand

Caching result of `root-config --cflags --libs`
Cached


You can also try to run the command from the pre- or pos-build steps of the program (without the backticks), to see the output of it, if it is run in the context of C::B.
If it has an error, C::B will cache nothing and expand the backticked command to ... nothing.

[JasperC]

Thanks again.  I think I know where I've gone wrong now... :oops:  Though I might still need help to fix it.

If you start C::B from a console with the -d parameter:

Code Select Expand

codeblocks -d
you should have an additional tab in "Logs & others" called "Code::Blocks Debug".

After opening your project you can onspect it and see, whether there is an entry like:

Code Select Expand

Caching result of `root-config --cflags --libs`
Cached


You can also try to run the command from the pre- or pos-build steps of the program (without the backticks), to see the output of it, if it is run in the context of C::B.
If it has an error, C::B will cache nothing and expand the backticked command to ... nothing.

So I did that and the build process worked fine...  Then I started a new Terminal window and tried again - this time it didn't work.  Then I remembered that for my first Terminal window, the one where I normally work from, I manually run a script to set up the environment:

Code Select Expand

. /home/jasper/gate/root_5.28.00e/bin/thisroot.sh

I would have thought that that sets the variables for everything else, but it appears to only affect the current Terminal window (and apparently applications launched from it).  And normally I start C::B from the launcher...

This line appears under the "Code::Blocks Debug" tab in both cases:

Code Select Expand

Caching result of `root-config --cflags --libs`
Cached

but with nothing else that I can see that indicates success or failure. (Am I looking in the wrong place?)

When successful, `root-config --cflags --libs` expands normally.


New question then, is it possible to get C::B to run the script before calling g++?  I'm making the assumption that C::B is internally creating it's own "session" to do the compile and link.  I've tried adding the above script command to

Project -> Build options... -> [Project name] -> [GNU GCC Compiler] -> Pre/post build steps -> Pre-build steps

but the build fails, and the build log shows:

Code Select Expand


Running project pre-build steps
. /home/jasper/gate/root_5.28.00e/bin/thisroot.sh
/home/jasper/gate/root_5.28.00e/bin/thisroot.sh: 25: Bad substitution
Process terminated with status 2 (0 minutes, 0 seconds)
0 errors, 0 warnings



Removing the leading ". " I get:

Code Select Expand


Running project pre-build steps
/home/jasper/gate/root_5.28.00e/bin/thisroot.sh
/bin/sh: /home/jasper/gate/root_5.28.00e/bin/thisroot.sh: Permission denied
Process terminated with status 126 (0 minutes, 0 seconds)
0 errors, 0 warnings


[Jenna]

If you only need to run root-config, you can run it with full absolute pathname:

Code Select Expand

`/path/to/root-config --cflags`
in the "Compiler options -> Other options" and

Code Select Expand

`/path/to/root-config --libs`
in the "Linker settings -> Other linker options".
It might be useful to put it in the global compiler settings, if you have created a special compiler for root.

About the issue running the shell-script:
I don't know why it fails, looks like missing execution rights for the user who runs C::B, or a script-error.
But this leaves the scope of our forum, sorry.

[JasperC]

Hi Jens, not a problem.  Thanks for all you help.    (And the solution you suggested does seem to work.)