Experimental Physics and
Industrial Control System

Mark Rivers via Tech-talk <[email protected]> · Fri, 23 Aug 2019 11:42:25 +0000

Hi Jörn.

Looking with "sumo-scan -t" at what is done during the process, Isee a small
difference between the areaDetector and all other modules:

git -C .../modules/src/areaDetector/3-7/ADSupport status --porcelain

returns nothing, while e.g.

git -C .../modules/src/iocStats/3.1.15 status --porcelain

returns

 M configure/RELEASE

?That is because the RELEASE files in areaDetector do not need to be locally modified, it is RELASE*.local files that get modified, and they are in .gitignore.  What gets distributed in git is EXAMPLE_RELEASE* files.  My understanding is that the use of RELEASE.local files is being encouraged because then "git status" does show no local modifications.

Your path to ADSupport looks like this:
   modules/src/areaDetector/3-7/ADSupport

That does not seem quite right because it does not encode the module version of ADSupport, which would be 1-9 for the current release for example.

> I need to setup a procedure to roll out a set of EPICS modules for a project that will be installed also off site by inexperienced persons.

I have been doing that for a long time using scripts like https://github.com/areaDetector/areaDetector/blob/master/makeADPrebuilt.

This builds tar and zip files that can be run "out of the box" by only editing the envPaths file in the iocBoot directory.  It does not require running "make" at all on the off-site system.  This is particularly useful for installing Windows IOCs where setting up an EPICS build system is not something inexperienced persons can easily do.

Mark

________________________________
From: [email protected] <[email protected]> on behalf of Jörn Dreyer via Tech-talk <[email protected]>
Sent: Friday, August 23, 2019 1:17 AM
To: [email protected]
Subject: Sumo test

Hi,

the discussion about sumo triggered me to take a look at this tool to figure
out if it can helm me to solve a problem I currently have. I need to setup a
procedure to roll out a set of EPICS modules for a project that will be
installed also off site by inexperienced persons. And looking at the
documentation sumo would exactly do what I need. I would configure my IOC
application using sumo and the locally installed modules. Then I would roll
out the application together with the sumo config files and it would be a few
well documented steps to get the IOC compiled an running.

Currently I have a set of shell scripts, a set of patches for the
configuration files and a Makefile to do the job. But as the configuration
files change with every new release, I need to create the patches on a regular
basis. That step I would like to get rid off.

So I installed all EPICS modules I need, together with base in the directory
structure needed by sumo (modules/src/<module name>/<module version>).
Then I ran sumo-scan on the modules directory to get the configuration. All my
modules where clonedout from github and the latest tag was checked out. Much
to my surprise sumo-scan put all modules as "path" type, only areaDetector sub
modules (besides aravisGigE) where detected as "git" repositories.

Looking with "sumo-scan -t" at what is done during the process, Isee a small
difference between the areaDetector and all other modules:

git -C .../modules/src/areaDetector/3-7/ADSupport status --porcelain

returns nothing, while e.g.

git -C .../modules/src/iocStats/3.1.15 status --porcelain

returns

 M configure/RELEASE

Which I needed to change to be able to define all the depended modules.
So here I#m stuck. Do I realy have to create the dependency file by hand?

Any tips and ideas welcome!

Regards

Jörn Dreyer

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System