Issues with r.8093

[ironhead]

As a result of the 8093 changes the NassiShneiderman plugin no longer compiles and on there seems to be a missing plugins\contrib\cbGcov\cbGcov.cbp project.

I fixed the NassiShneiderman plugin by changing #boost.include search directory back to #boost in the C::B project file.

[MortenMacFly]

As a result of the 8093 changes the NassiShneiderman plugin no longer compiles

It does, if you setup the global compiler var correctly. For boost, the include member should always be "$(#boost.base)". Depending on if/how you compiled / using boost, the lib member needs to be adjusted, too.

and on there seems to be a missing plugins\contrib\cbGcov\cbGcov.cbp project.

This was indeed an error. Fixed in SVN.

[oBFusCATed]

Morten: Are you saying that the include and lib fields can have the base in them? Something like include="$(#mylib.base)/inlcude" ?

[MortenMacFly]

Morten: Are you saying that the include and lib fields can have the base in them? Something like include="$(#mylib.base)/inlcude" ?

Yes, of course. You have to do it that way for libs like boost that do not have a proper "include" folder named like that.

MacrosManager handles this just fine as using "base" as a reference causes no endless loop (of course not, if you use it in the "base" field itself ;-)). I am using this extensively, for example also for portability stuff.

[ironhead]

For the 'boost' global variable I have base set to 'C:\boost_1_49_0' (where my boost install is located). All other variables (include / lib / obj) are empty.  If I understand correctly, you're saying I need to set the 'include' variable to '$(#boost.base)'?  How come I don't need to do this for 'wx'?

[MortenMacFly]

If I understand correctly, you're saying I need to set the 'include' variable to '$(#boost.base)'?

Yes.

How come I don't need to do this for 'wx'?

Because wxWidgets has an "include" and "lib" folder named as the fields of the GCV. GCV's are replaced like the field-names by default, if the entry is empty. So... by default for boost this means:

Code

$(#boost.include) = [Boost base Path]\include
$(#boost.lib) = [Boost base path]\lib

...ans so on - which is incorrect for boost as you see.
Setting the field of $(#boost.include) to $(#boost.base) will resolve the boost GCV in way, that the includes will work, as they are not under [Boost base path]\include, but directly under [Boost base path].

That's what the concept of GCV's is for in the end and what differs them from environment / custom variables.

Note that using plain $(#boost) as compiler include path is actually not precisely correct. That's why I've changed it.

Edit: See also here:
http://wiki.codeblocks.org/index.php?title=Global_compiler_variables

[oBFusCATed]

off: Maybe I've to read the whole page for global variables as I've learned another useful thing...

[MortenMacFly]

off: Maybe I've to read the whole page for global variables as I've learned another useful thing...

Well this concept is very powerful and unique for our IDE. Unfortunately it seems also well hidden and not obvious in the first place.

When we didn't have the platform flag I was using the GCV's to become a cross platform project file:
I created a "platform" GCV and in its "custom fields" I entered something like "lib_ext = .dll" and "app_ext = .exe" for Windows and "lib_ext = .so" and "app_ext = (empty)" for Linux (syntax here "field_name = value"). Then for the projects' target's output name I setup "mylib$(#platform.lib_ext)" and "myapp$(#platform.app_ext)" which was working fine once setup per platform. Luckily meanwhile this is even simpler, but maybe another nice use-case for GCV's.