How to see the generated compiler parameters?

[cacb]

I am compiling a few Code::Blocks projects with wxWidgets, using wx-config. I have a configuration issue on Linux and need to see what exactly Code::Blocks is saying to the compiler, i.e. the compiler and linker command line parameters.

Where can I find the fully expanded cimpiler parameters?

[oBFusCATed]

Read here: http://wiki.codeblocks.org/index.php?title=FAQ#Q:_How_do_I_troubleshoot_an_compiler_problem.3F

[cacb]

Read here: http://wiki.codeblocks.org/index.php?title=FAQ#Q:_How_do_I_troubleshoot_an_compiler_problem.3F

Thank you, that gave me exactly what I was looking for!  I can see the options generated now.

The problem I trying to solve is that I don't seem to have 100% control over which wx-config I am using in Linux build targets, thereby leaving a big 'hole' in the configuration of Code::Blocks projects using wxWidgets. My projects have compiler settings like this

Code

<Compiler>
	<Add option="-Wall" />
	<Add option="-g" />
	<Add option="`wx-config --version=2.8 --toolkit=gtk2 --debug --cxxflags`" />
	<Add option="`wx-config --cflags`" />
	<Add option="-DNOPCH" />
	<Add option="-D__WXDEBUG__" />
	<Add option="-D_DEBUG" />
	<Add option="-D__WX__" />
</Compiler>

As I have a locally compiled version of wxWidgets (using static libraries, among other things), I was trying to tell Code::Blocks to use the wx-config found in /usr/local/bin by means of the Code::Blocks global variable "wx" (defined as /usr/local):

Code

<Compiler>
	<Add option="-Wall" />
	<Add option="-g" />
	<Add option="`$(#wx)/bin/wx-config --version=2.8 --toolkit=gtk2 --debug --cxxflags`" />
	<Add option="`$(#wx)/bin/wx-config --cflags`" />
	<Add option="-DNOPCH" />
	<Add option="-D__WXDEBUG__" />
	<Add option="-D_DEBUG" />
	<Add option="-D__WX__" />
</Compiler>

However, this didn't work, as it now becomes clear that Code::Blocks global variables don't get expanded in the context of "backticks". So instead I had to manually expand it to

Code

<Compiler>
	<Add option="-Wall" />
	<Add option="-g" />
	<Add option="`/usr/local/bin/wx-config --version=2.8 --toolkit=gtk2 --debug --cxxflags`" />
	<Add option="`/usr/local/bin/wx-config --cflags`" />
	<Add option="-DNOPCH" />
	<Add option="-D__WXDEBUG__" />
	<Add option="-D_DEBUG" />
	<Add option="-D__WX__" />
</Compiler>

Which isn't 100% general, as I would like everything to be dependent in the wx global variable. Any tips on how to achive it is welcome.

But you answered my original question, so thanks for that 

[oBFusCATed]

Add /usr/local/bin to your PATH, you can probably use the envvar plugin.
I think there is a way to combine all wx-config scripts in one, but I don't know how.
Probably you should ask the wx guys.

p.s. you should remove the `wx-config --cflags`

[cacb]

Add /usr/local/bin to your PATH, you can probably use the envvar plugin.
I think there is a way to combine all wx-config scripts in one, but I don't know how.
Probably you should ask the wx guys.

I see, but the idea was to keep as much configuration as possible in the .cbp file. If you share the project file with others it is important. But it is a good idea to learn more about wx-config from the wx guys.

p.s. you should remove the `wx-config --cflags`

Aha. Thanks.

[Jenna]

It would be easy to expand macros in backticked expressions before evaluating them:

Code

Index: compilercommandgenerator.cpp
===================================================================
--- compilercommandgenerator.cpp	(Revision 7071)
+++ compilercommandgenerator.cpp	(Arbeitskopie)
@@ -919,6 +919,7 @@
 /** Adds support for backtick'd expressions under windows. */
 wxString CompilerCommandGenerator::ExpandBackticks(wxString& str)
 {
+    Manager::Get()->GetMacrosManager()->ReplaceMacros(str);
     wxString ret;
 
     // this function is not windows-only anymore because we parse the backticked command's output

@other devs:
Is there any obvious reason I miss not to do it ?

[MortenMacFly]

Is there any obvious reason I miss not to do it ?

Such things are usually dangerous for auto-generated files because the macros may be expanded too early. I didn't see when this is called though (no access to the sources). You should play the tutorial from the WiKi concerning auto-generated files and see it that would still work. If that's the case I see not reason not to do it.

Also, verify what gets saved to the project. Remember: This is a by reference call... not that we loose the original setup.

[Jenna]

Is there any obvious reason I miss not to do it ?

Such things are usually dangerous for auto-generated files because the macros may be expanded too early. I didn't see when this is called though (no access to the sources). You should play the tutorial from the WiKi concerning auto-generated files and see it that would still work. If that's the case I see not reason not to do it.

Which tutorial ?

Also, verify what gets saved to the project. Remember: This is a by reference call... not that we loose the original setup.

Both calls to ExpandBackticks use temporary strings at the moment, so it does not harm.
And what's more the actual code also changes the wxString passed to the function (it replaces the backtick-part with the evaluated stuff).

[cacb]

Both calls to ExpandBackticks use temporary strings at the moment, so it does not harm.
And what's more the actual code also changes the wxString passed to the function (it replaces the backtick-part with the evaluated stuff).

Just saying that I appreciate your efforts here... It would indeed be useful to allow the expansion inside backticks! As mentioned, it is obviously important that the expanded string is not written back to the .cbp file. It must be left as written.

[MortenMacFly]

Which tutorial ?

This one:

http://wiki.codeblocks.org/index.php?title=Adding_support_for_non_C/C%2B%2B_files_to_the_build_system

(Sorry, forgot to mention that...)