EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Using V4 pvCommonCPP module with external boost library
From: <[email protected]>
To: <[email protected]>, <[email protected]>
Date: Wed, 28 Oct 2015 21:07:47 +0000
Hi Alan,

[I see that as I was writing this Andrew's also written a reply. I think this should still be useful.]

The lines you quoted:

"In addition for C++ there is the utility module pvCommonCPP. This contains boost, needed in particular for shared_pointers, and a microbenchmark framework. If you don't intend to use the latter then you may not need pvCommonCPP, depending on your compilers support for shared_pointers."

are from the latest version of the getting started guide, which, as it states in the Status section, is up to date with respect to the 4.5 release. Since you're using 4.4 you may want to look at the previous version of the guide.

The answers to your questions will be slightly different depending on whether you stick with 4.4 or move to 4.5. 

> 2) Should the other V4 modules have been released against this pvCommonCPP module?

For 4.4 you still need pvCommon, even if you don't need shared_pointers for your host/compiler and the microbenchmarking. pvAccessCPP uses various microbenchmarking macros, which are defined in pvCommonCPP (mbSrc/mb.h) and pulled in in pvAccessMB.h. When microbechmarking is disabled (which it is by default) these macros expand to nothing, but the macro definitions are still in pvCommonCPP. So without patching the source pvAccessCPP needed to be released against pvCommonCPP for all hosts and build options. The same is true of pvaSrv. Generally pvCommonCPP was treated as a dependency for the V4 modules, but I think the other modules could be released without the pvCommonCPP dependency in the case of no microbenchmarking and compiler support for shared_pointers.

For 4.5 the non-microbechmarking definitions of the microbechmarking macros are in pvAccessCPP (pvAccessMB.h), so if you don't need the shared_pointer definitions you don't need pvCommonCPP to build pvAccessCPP when there is compiler support for shared_pointers.

> 1) Is pvCommonCPP required when compiling against V4 modules?
 
For 4.4, unless your application explicitly includes pvAccessMB.h or pvCommonCPP headers or links against pvMB (unnecessarily) then for compilers with shared_pointer support and microbenchmarking disabled, you should be able to compile against  V4 modules without adding pvCommonCPP to your RELEASE(.local), but you still need pvCommonCPP from the point of view of building pvAccess. I tried for ADCore with V4 plugins and that built without specifying pvCommonCPP in RELEASE.local.

For 4.5 for compilers with shared_pointer support and microbenchmarking disabled you should be able to do without pvCommonCPP (unless, again, your application explicitly includes pvAccessMB.h or pvCommonCPP headers or links against pvMB).

> 3) If pvCommonCPP is required is there a way to specify which version of boost it can be compiled against?

Not sure what you mean here. pvCommon doesn't need to be compiled against boost. If you mean your application, I suspect that in your case you won't actually be including pvCommon's boost headers or linking against the pvCommon boost, so you may be able to build against your boost.

> 4) If using pvCommonCPP along with its version of boost, does the whole set of boost libraries get built and installed?

By default no - it's controlled by a macro WITH_ALL_BOOST. Set to 1 (e.g in a CONFIG_SITE.local pulled in by pvCommonCPP's CONFIG_SITE) to build and install everything.

Regards,

Dave

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: 28 October 2015 14:23
To: [email protected]
Subject: Using V4 pvCommonCPP module with external boost library

Hello,

I have run into a problem when building the V4 pvCommonCPP module into an IOC that also makes use of boost libraries.

My setup is

Red Hat Enterprise Linux Workstation release 6.7 (Santiago) pvCommonCPP version 4-0-2 (looking at README suggests boost version 1-53-0) external boost installation version 1-48-0 Specifically I'm compiling ADCore 2-4 with V4 plugin/driver (V4 dependency) enabled and pluginTest unit tests (external boost dependency) enabled.

I cannot compile my application because the boost header files inside pvCommonCPP are found and are not compatible, and so I have the following questions...

1) Is pvCommonCPP required when compiling against V4 modules?  The V4 documentation has

"In addition for C++ there is the utility module pvCommonCPP. This contains boost, needed in particular for shared_pointers, and a microbenchmark framework. If you don't intend to use the latter then you may not need pvCommonCPP, depending on your compilers support for shared_pointers."

which suggests I wouldn't need it?  However, other V4 modules have been released against this version of the pvCommonCPP module and so the reference exists if I include any V4 modules.

2) Should the other V4 modules have been released against this pvCommonCPP module in my case, or could they have been released without the reference as I have shared pointers available anyway?

3) If pvCommonCPP is required is there a way to specify which version of boost it can be compiled against?

4) If using pvCommonCPP along with it's version of boost, does the whole set of boost libraries get built and installed?

Thanks, Alan


--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom




References:
Using V4 pvCommonCPP module with external boost library alan.greer

Navigate by Date:
Prev: Re: Using V4 pvCommonCPP module with external boost library Andrew Johnson
Next: Driver for Amptek XR-100SDD Silicon Drift Detector? J. Lewis Muir
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Using V4 pvCommonCPP module with external boost library Andrew Johnson
Next: Driver for Amptek XR-100SDD Silicon Drift Detector? J. Lewis Muir
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024