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: Siniša Veseli <[email protected]>
To: <[email protected]>
Date: Wed, 16 Nov 2016 10:33:11 -0600
Hi,

I must say that the recent ADCore build changes are indeed excellent. For APSU software we utilize only ADCore base functionality, plus small number of standard plugins, and Mark's approach allowed us to get away from patching ADCore default makefiles in order to get rid off various libraries/plugins that we do not need (or do not have) for various platforms that we support.

We also utilize some other open source products and libraries, which we install separately from the EPICS application code, and integrate with EPICS build via RELEASE.local files.

Sinisa


On 11/16/16 10:15 AM, Mark Rivers wrote:
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: [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



--
Siniša Veseli
Scientific Software Engineering & Data Management
Advanced Photon Source
Argonne National Laboratory
[email protected]
(630)252-9182


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: Philosophy regarding use of open source libraries for EPICS Mark Rivers
Next: RE: Modbus Device Support for Advantech ADAM6017, 6018 Mazanec Tomáš
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 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  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 ·