RE: EPICS Application Package

[Hinko Kocevar <Hinko.Kocevar@esss.se>]

Dear,

 

On 2018-10-12 17:12:24+02:00 tech-talk-bounces@aps.anl.gov wrote:

Hi Bo,

Yes, I was referring to the ESS EPICS setup, which has been developed based on the PSI implementation.

 

And: no, there is no way to get this working with just a "normal base" system. That run-time module resolution and linking mechanism is a complicated beast, and needs additional tools and services.

Bugs in such setups have the tendency to show up at run time as spontaneous core dumps.

As a user of the ESS EPICS environment, I've been there. IOC was not starting due to broken dependencies not being resolved at runtime as expected, while I had nothing to do with the changes that caused my IOC to fail to start. I would recommend not to go down this path, if you have the choice, even if it seems attractive as it does. The reasons for not being in favor of such approach are purely empirical, while some folks at PSI/ESS might have a success story to share.

The EPICS build system is something one needs to get used to. During the years of being involved with EPICS, I settled to have builds for the IOC and support modules to be explicitly defined in configuration files, just as EPICS build system was designed to deal with them.

To avoid hand editing the RELEASE files each time I have an IOC to build, I've coded a python script that takes a 'recipe' for base/module/IOC containing some meta data, including top package dependencies, and delivers a set of built packages - found while resolving deps at compile time.

The reason for sticking with the EPICS build system is mainly because I can get all the support I need from this mailing list, when things take the turn for the worse, as opposed to being more or less on my own with some customized EPICS runtime solution.

YMMV.

Cheers,
Hinko
 

 

Starting from "normal base", your basic option is shared libraries vs. statically built binaries. When using shared libraries, you have to make sure that the right versions of the right libraries are in the right place when running the IOC. EPICS won't help you with that, so people use package managers or containers to do this.

If you build statically, you can usually get by with tarring up the installation directories of your IOC application, and extracting that archive on the machine that will run the IOC.

That is a lot easier and pretty robust.

Cheers,
~Ralph

 

On Fri, 12 Oct 2018 at 16:23, Bo Jakobsen <lister@f77.dk> wrote:

Hi

I am also very interested in this thread as I am working on a new setup.
I worked with the below described configuration when working with the ESS EPICS setup, but could you please provide some information on how to do this from the "normal base" epics system. All demos and docs I have seen ends up with compiling the ioc binary including the support libraries in the process.


On 2018-10-12 09:37, Ralph Lange wrote:

Other institutes are using an NFS mounted repository of all applications and shared libraries and a database of versions of tested combinations of these, and load device support and EPICS modules dynamically from the startup script of the IOC. This also needs a careful design and serious building infrastructure in the background, but maybe requires less upfront work and learning compared to the first option.

Best
    Bo