Experimental Physics and
Industrial Control System

"Kasemir, Kay" <[email protected]> · Wed, 16 Nov 2016 16:15:04 +0000

Hi:

We had very similar discussions for CS-Studio.

Originally, we included the CS-Studio dependencies in our sources, i.e. we had a copy of the JAR files for accessing oracle, mysql, JMS, Channel Access.
That made for very easy and repeatable builds:
Unzip a snapshot of the CS-Studio sources (which include 3rd party JAR files), import into Eclipse or invoke the equivalent of "make", done.

But this obviously results in a growing source repository.
First we moved all the 3rd party JARs into their own source repository.
Then we switched to using Maven as a build system, and removed many of the 3rd party binaries from our source repos.
Maven downloads the 3rd party libraries from somewhere on the internet.
There are days where it can't find them, or it picks a newer version because we didn't take enough care to specify the exact version that we need.
While our current approach "works" on most days, saves some space in the repository and is buzzword compliant, it does take longer to build.
Newcomers tend to need about a week to get to their first successful build setup.
At least for me, the earlier approach of having the plain JAR files together with the sources was easier to understand and 100% repeatable.

Of course there's the other question of where you draw the line between what you provide and what you expect to already be there.
For CS-Studio, we expected a certain version of Java and the Eclipse IDE to be present, the rest was provided as source or JAR.
Now we expect java, maven, and cs-studio sources. The rest, including eclipse, is provided by the internet.

-Kay

________________________________________
From: [email protected] <[email protected]> on behalf of Rod Nussbaumer <[email protected]>
Sent: Wednesday, November 16, 2016 10:43 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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System