Re: Basic EPICS bootstrap (rant)

[Anders Lindh Olsson via Tech-talk <tech-talk@aps.anl.gov>]

Hi,

 

Another alternative is to us ESS’ “e3”. You can find the docs for our current production setup at http://e3.pages.esss.lu.se/e3-build-tools/, and the docs for our newer setup – not yet entirely released – at http://e3.pages.esss.lu.se.

 

We have also used .deb packages and similar in limited contexts, but find that to not scale too well (at least for our usages).

 

 

Cheers

Anders

 

From: Tech-talk <tech-talk-bounces@aps.anl.gov> on behalf of Ulrik Pedersen via Tech-talk <tech-talk@aps.anl.gov>
Date: Wednesday, 8 October 2025 at 11:53
To: Graeme Winter <gw363@cornell.edu>
Cc: tech-talk@aps.anl.gov <tech-talk@aps.anl.gov>
Subject: Re: Basic EPICS bootstrap (rant)

Hi Graeme,

 

The EPICS build system has a long and glorious history and yes, it is not very fashionable and a little bit manual to build modules. Fortunately modules are very stable and once you have built up an EPICS environment you typically will not need to update many modules often.

 

It sounds like what you are after is basically an EPICS package repository to enable easy installation of modules. There have been numerous attempts at building and maintaining such things over the years but this is really a non-trival amount of effort and most facilities have ended up with a bespoke solution, in many cases just by building EPICS & modules into a network file system (i.e. /dls_sw/prod/epics/)

 

There are some more attempts by the community to provide repositories:

• EPICS containers is going quite strong. It includes a large selection of EPICS base & modules built into container images for both development and production

• https://epics-containers.github.io/main/index.html

• NSLS-II used to keep a Debian repo up-to-date but it seems the last supported distro was Debian Buster, so I guess this is no longer active

• https://epicsdeb.bnl.gov/debian/ 

• EPICS Sumo is another custom repo/installer application. Interestingly it is located not on github like most stuff today but on sourceforge!

• https://epics-sumo.sourceforge.io/

• ci-scripts is intended to run inside CI pipelines but presumably you can run the scripts locally to install a set of EPICS modules. This is updated regularly and probably my best recommendation to look into today.

• https://github.com/epics-base/ci-scripts

• Homebrew for Mac (and Linux now). This is really my own personal wish - to have a homebrew tap for easy EPICS installation on macos and for arm64. I haven't found this elsewhere so I did once a few years ago tinker and created my own. Eventually abandoned it because the CI was very complex, I hated the Ruby scripting, and the linting was very very strict and constantly broke builds: basically too much work for just me to build and maintain in my spare time. It might have got easier/better since(?) Here are the bits in case you're interested:

• https://github.com/ulrikpedersen/homebrew-mytap

Cheers,

Ulrik

 

 

On Tue, 7 Oct 2025 at 19:56, Graeme Winter via Tech-talk <tech-talk@aps.anl.gov> wrote:

Good afternoon

 

Working through 

 

Getting Started epics-controls.org

 

 

It really feels like this is something which could be made _much_ easier by writing a kind of bootstrap script but also by the configure process being able to pick up stuff from the environment rather than having to hard-code every location multiple times in every configuration file (where the defaults are of course where the author does _their_ epics development) - the need for them to all correctly cross-reference is also an irritation

 

Before I scrape another few mm off my already suffering sanity - 

 

- _has_ anyone got a bootstrap script which will clone / install all the necessary / regular support modules

- am I holding it wrong / reading the wrong getting started guide

 

I note I can conda install epics-base but this _only_ gives epics base

 

That rant to one side, also, does anyone know how to address a missing symbol issue like

 

Undefined symbols for architecture arm64:

  "_pvar_func_vxi11RegisterCommands", referenced from:

      _cryo1_registerRecordDeviceDriver in cryo1_registerRecordDeviceDriver.o

ld: symbol(s) not found for architecture arm64

 

The symbol is indeed missing and would appear to be from asyn/vxi11/drvVxi11.c but does not appear to be built

 

This got me thinking I should re-do the NN steps to get back to here which then got me wondering about process itself…

 

Thanks Graeme