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: Goetz Pfeiffer via Tech-talk <tech-talk@aps.anl.gov>
To: Jörn Dreyer <j.dreyer@hzdr.de>, <tech-talk@aps.anl.gov>
Date: Fri, 30 Aug 2019 14:03:15 +0200
Hello Jörn,

sumo-scan is intended to help migrating an existing support directory that
contains many EPICS supports to sumo.

It therefor scans the directories, tries to determine remote repositories,
scans RELEASE files for module dependencies and creates entries for the sumo
database.

The resulting sumo database can then be used to recreate the support
directories.

If the program finds that the working copy of a support has modified files with
respect to version control, it sets the type to "PATH", since it cannot
recreate that directory solely from a version in the repository.

Since with EPICS we often modify the file "configure/RELEASE" locally without
recording that change, it is in most (maybe all) cases useful to ignore changes
in configure/RELEASE.

You can do this with option "--ignore-changes" as described here:

  https://goetzpf.bitbucket.io/sumo/reference-sumo-scan.html

In your case the option would be:

  --ignore-changes configure/RELEASE

Other useful options may be:

  --ignore-name NAME : ignore variable NAME in scanned RELEASE file.
  --url-patch REGEXP : modifiy repository URLs by a regular expression
 
Finally here is a sumo-scan configuration file I used at the HZB to scan our support directory:

-------------
{
    "dir": [
        "/opt/csr/Epics/R3.14.12/base/3-14-12-2-1",
        "/opt/Epics/R3.14.12/support"
    ],
    "exclude-deps": "home/",
    "exclude-path": [
        "apps/crateCtrl/XXXXX",
        "busy/vendor",
        "monoapps",
        "std/vendor",
        "devIocStats/vendor"
    ],
    "group-basedir": [
        "/opt/Epics/R3.14.12/support",
        "/opt/Epics/R3.14.12"
    ],
    "hint": [
        "apps/crateCtrl/3-0,TAGLESS",
        "apps/genericTemplate/3-2,TAGLESS",
        "apps/iocWatch/2-3,TAGLESS",
        "apps/vacuum/1-0-1,TAGLESS",
        "apps/vacuum/1-0-2,TAGLESS",
        "apps/vacuum/1-1,TAGLESS"
    ],
    "ignore-name": [
        "TOP",
        "EPICS_SUPPORT",
        "SUPPORT",
        "TEMPLATE_TOP",
        "EPICS_SITE_TOP",
        "EPICS_MODULES",
        "MSI"
    ],
    "missing-repo": null,
    "missing-tag": null,
    "progress": true,
    "url-patch": [
        "r\"^([^:]*)$\",r\"rcsadm@repo.acc.bessy.de:\\1\"",
        "r\"^([^@]*)$\",r\"rcsadm@\\1\"",
        "r\"\\b(aragon)(?:|\\.acc):\",r\"\\1.acc.bessy.de:\"",
        "r\"\\b(repo)(?:|\\.acc):\",r\"\\1.acc.bessy.de:\"",
        "r\"^rcsadm@localhost:\",r\"rcsadm@aragon.acc.bessy.de:\"",
        "r\"^rcsadm@localhost:\",r\"rcsadm@repo.acc.bessy.de:\"",
        "\":darcs-repos\",\":/opt/repositories/controls/darcs\"",
        "r\"/srv/csr/Epics\",\"/opt/Epics\"",
        "r\"/(srv|opt)/csr/(repositories/controls/darcs)\",r\"/opt/\\2\""
    ],
    "dir-patch": [
        "r\"/srv/csr/Epics\",\"/opt/Epics\"",
        "r\"/(srv|opt)/csr/(repositories/controls/darcs)\",r\"/opt/\\2\""
    ]
}
-------------

Greetings
  Goetz


On 8/30/19 10:08 AM, Jörn Dreyer via Tech-talk wrote:
> 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
>
>
>


Attachment: signature.asc
Description: OpenPGP digital signature


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

Navigate by Date:
Prev: Re: Cross compiling Florian Feldbauer via Tech-talk
Next: Re: Cross compiling Jeong Han Lee 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 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, 16 Sep 2019 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·