Re: Philosophy regarding use of open source libraries for EPICS

[Siniša Veseli <sveseli@aps.anl.gov>]

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: 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
--
Siniša Veseli
Scientific Software Engineering & Data Management
Advanced Photon Source
Argonne National Laboratory
sveseli@anl.gov
(630)252-9182