Experimental Physics and Industrial Control System
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\"[email protected]:\\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\"[email protected]:\"",
"r\"^rcsadm@localhost:\",r\"[email protected]:\"",
"\":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: [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
>
>
>
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
<2019>
2020
2021
2022
2023
2024
- 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
<2019>
2020
2021
2022
2023
2024