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: Jörn Dreyer via Tech-talk <tech-talk@aps.anl.gov>
To: tech-talk@aps.anl.gov
Date: Fri, 30 Aug 2019 10:08:55 +0200
Hello,

I partialy was able to solve the issue.
The sumo-scan tool expects the output of the repository programs in English 
language. My system was setup tu use LANG=de_DE.UTF-8. Changing this to 
LANG=en_EN.UTF-8 solved parts of the problem.

But still a problem remains. To configure a modules one has to modify the 
RELEASE file. Most modules do not use new files for configuration like the 
areaDetector module. In addition I had to change the Makefile in the 
aravisGige directory to be compatible with my x86_64 system, where aravis gets 
installed in lib64 instead of lib directory. 

Looks like I have to create the configuration file for sumo by hand.

Regards

Jörn


Am Freitag, 23. August 2019, 13:42:25 CEST schrieb Mark Rivers:
> 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 Goetz Pfeiffer via Tech-talk
References:
Sumo test Jörn Dreyer via Tech-talk
Re: Sumo test Mark Rivers via Tech-talk

Navigate by Date:
Prev: RE: areaDetector NDPluginTimeSeries errors Mark Rivers via Tech-talk
Next: Re: Cross compiling 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: Re: Sumo test Mark Rivers via Tech-talk
Next: Re: Sumo test Goetz Pfeiffer 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 ·