RE: Philosophy regarding use of open source libraries for EPICS

[Mark Rivers <rivers@cars.uchicago.edu>]

Hi Rod,

The areaDetector release I did recently (R2-5 of areaDetector and ADCore) is a good example of the point you bring up.  I added a new ADSupport directory which is used for building support libraries from source code.  These are
libz, szip, xml2, netCDF,  tiff, jpeg, hdf5,  and nexus.  They are all independent of EPICS, except that I converted each of these packages to build with the EPICS build system, and made patches to allow them to build on all support platforms (linux-x86, linux-x86_64, win32-x86, window-x64, win32-x86-mingw, linux-x86.win32-x86-mingw, wxWorks-ppc32).  For each library XXX the user configures (via CONFIG_SITE) the following 4 options

WITH_XXX = [YES,NO]  
    Use this library at all.  If no then any areaDetector components that depend on this library will not be built

XXX_EXTERNAL=[YES,NO]  
    If YES then the XXX package must be installed outside of areaDetector.  If NO then this library will be built in ADSupport

XXX_LIB  
    If XXX_EXTERNAL=YES then this can give the path to the XXX library files

XXX_INCLUDE
    If XXX_EXTERNAL=YES then this can give the path to the XXX library files

This allows lots of flexibility.  On Unix one might use XXX_EXTERNAL=YES for some libraries (e.g. tiff, jpeg, z, xml2) and XXX_EXTERNAL=NO for other (e.g. hdf5 because you want the more recent version in ADSupport than the system installed version, etc.)  On Windows and VxWorks typically there is no convenient way to install most of these packages, so they will typically set XXX_EXTERNAL=NO for all libraries.

Mark


-----Original Message-----
From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Rod Nussbaumer
Sent: Wednesday, November 16, 2016 9:44 AM
To: epics Techtalk
Subject: Philosophy regarding use of open source libraries for EPICS

All:

I would like to get peoples' opinions about the right way to deal with 
open source third party libraries that get bound to EPICS applications, 
particularly on Linux, but wherever else it comes into play. An example 
case would be libgif, which can be used by EDM to display GIF images in 
EDM screens. The Area Detector package seems to make significant use of 
such libraries for image processing. So far, the standard procedure here 
has been to install the libraries from binary repositories supported by 
OS vendors such as Redhat, Debian, etc. We do this on development hosts 
and the matching production host architectures. However, this leaves us 
vulnerable to incompatible changes that may be introduced due to routine 
maintenance of the hosts, and silently changes the deployed EPICS 
software with no knowledge of the effect, or testing that it works as 
expected. The alternative would be to build from sources, all libraries 
that go into an EPICS application, and install the lib binaries in a way 
that they get used in lieue of the system-installed packages. Does 
anyone do that? Am I being paranoid? The obvious question is how far 
would you take this approach, since literally everything binds to libc, 
libm, and some other standard libraries.
Thanks in advance for your opinions.

Rod Nussbaumer
TRIUMF
Vancouver, Canada