EPICS Controls Argonne National Laboratory

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  2015  <20162017  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  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Philosophy regarding use of open source libraries for EPICS
From: Mark Rivers <[email protected]>
To: "'Rod Nussbaumer'" <[email protected]>, epics Techtalk <[email protected]>
Date: Wed, 16 Nov 2016 16:25:30 +0000
Sorry, my previous post had a number of typos that could cause confusion, and lacked some explanation of the history.  Here is a new version.

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 supported platforms (linux-x86, linux-x86_64, win32-x86, windows-x64, win32-x86-mingw, linux-x86.win32-x86-mingw, vxWorks-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 include files

This allows lots of flexibility.  On Linux 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 there is no convenient way to install most of these packages, so they will typically set XXX_EXTERNAL=NO for all libraries and build from source in ADSupport. 

Prior to R2-5 some libraries were always built from source in ADCore (netcdf and nexus on all platforms; tiff and jpeg on Windows).  Some libraries were provided pre-built for Windows in ADBinaries (xml2, hdf5).  Providing pre-built libraries on Windows was becoming unmaintainable because they often only worked with the release of Visual Studio they were built with, and required many versions (32/64-bit, static/dynamic, debug/release).  Providing all libraries as source in ADSupport and supporting the above options is much cleaner and easier to maintain.

Mark


-----Original Message-----
From: [email protected] [mailto:[email protected]] 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




References:
Philosophy regarding use of open source libraries for EPICS Rod Nussbaumer
RE: Philosophy regarding use of open source libraries for EPICS Mark Rivers

Navigate by Date:
Prev: Re: motor6-10 - thread hijack to "synApps documentation" J. Lewis Muir
Next: Re: Philosophy regarding use of open source libraries for EPICS Siniša Veseli
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Philosophy regarding use of open source libraries for EPICS Mark Rivers
Next: Re: Philosophy regarding use of open source libraries for EPICS Siniša Veseli
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Nov 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·