Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Issues with r.8093

(1/2) > >>

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:

--- Quote from: ironhead on July 08, 2012, 05:31:08 am ---As a result of the 8093 changes the NassiShneiderman plugin no longer compiles

--- End quote ---
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.

--- End quote ---
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:

--- 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" ?

--- End quote ---
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'?

Navigation

[0] Message Index

[#] Next page