Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
<== Date ==> <== Thread ==>

Subject: Re: Sumo test
From: Mark Rivers via Tech-talk <tech-talk@aps.anl.gov>
To: Jörn Dreyer <j.dreyer@hzdr.de>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: 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: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> on behalf of Jörn Dreyer via Tech-talk <tech-talk@aps.anl.gov>
Sent: Friday, August 23, 2019 1:17 AM
To: tech-talk@aps.anl.gov
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




Replies:
Re: Sumo test Jörn Dreyer via Tech-talk
References:
Sumo test Jörn Dreyer via Tech-talk

Navigate by Date:
Prev: Sumo test Jörn Dreyer via Tech-talk
Next: Re: EPICS 'isegHAL' module Florian Feldbauer via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
Navigate by Thread:
Prev: Sumo test Jörn Dreyer via Tech-talk
Next: Re: Sumo test Jörn Dreyer via Tech-talk
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  <20192020 
ANJ, 30 Aug 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·