Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: ironhead on July 08, 2012, 05:31:08 am

Title: Issues with r.8093
Post by: ironhead on July 08, 2012, 05:31:08 am
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.
Title: Re: Issues with r.8093
Post by: MortenMacFly on July 08, 2012, 06:11:39 am
Quote from: ironhead on July 08, 2012, 05:31:08 am
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.

Quote from: ironhead on July 08, 2012, 05:31:08 am
and on there seems to be a missing plugins\contrib\cbGcov\cbGcov.cbp project.
This was indeed an error. Fixed in SVN.
Title: Re: Issues with r.8093
Post by: oBFusCATed on July 08, 2012, 11:34:38 am
Morten: Are you saying that the include and lib fields can have the base in them? Something like include="$(#mylib.base)/inlcude" ?
Title: Re: Issues with r.8093
Post by: MortenMacFly on July 08, 2012, 02:19:12 pm
Quote from: oBFusCATed on July 08, 2012, 11:34:38 am
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.
Title: Re: Issues with r.8093
Post by: ironhead on July 08, 2012, 04:02:41 pm
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'?
Title: Re: Issues with r.8093
Post by: MortenMacFly on July 08, 2012, 04:14:49 pm
Quote from: ironhead on July 08, 2012, 04:02:41 pm
If I understand correctly, you're saying I need to set the 'include' variable to '$(#boost.base)'?
Yes.

Quote from: ironhead on July 08, 2012, 04:02:41 pm
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
Title: Re: Issues with r.8093
Post by: oBFusCATed on July 08, 2012, 04:26:24 pm
off: Maybe I've to read the whole page for global variables as I've learned another useful thing...
Title: Re: Issues with r.8093
Post by: MortenMacFly on July 08, 2012, 06:39:09 pm
Quote from: oBFusCATed on July 08, 2012, 04:26:24 pm
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.