RE: AreaDetector repository inconsistent

[Mark Rivers <rivers@cars.uchicago.edu>]

I think it would be good to have 2 types of scripts:

 

-          assemble_synApps_x_y.sh (or install_synApps_x_y.sh).  This would do a git clone, i.e. a fresh install.

-          update_synApps_x_y.sh.  This would assume that the tree already exists and just go into each module and do a git pull; git checkout y.z

 

Or perhaps a single script that just checks to see if the module exists and does a git clone if it does not.  How to handle different names people give the subdirectories? Require that there be a softlink called “asyn”, “calc”, etc. even if the directory is asyn-4-33?

 

Mark

 

 

From: Mooney, Tim M. [mailto:mooney@aps.anl.gov]
Sent: Wednesday, February 07, 2018 10:59 AM
To: Mark Rivers <rivers@cars.uchicago.edu>; Jemian, Pete R. <jemian@anl.gov>; tech-talk@aps.anl.gov
Subject: Re: AreaDetector repository inconsistent

 

I think synApps_x_y.sh is a good idea.  By the way, the reason that full synApps releases are not more frequent is not mostly about module incompatibilities, but more about our inability to test.  To thoroughly test synApps, you have to get it deployed on a beamline.  We don't have a test beamline, and beamline staff don't want to expose their users to questionable software.  They are willing to accept a new module version that hasn't been thoroughly tested if there is a bug fix or other improvement they need.  But they are not willing to risk problems from a module whose new features they don't care about.  So, as long as we can do single module upgrades, we do them.  This works until someone needs a new version of asyn, or seq, or some other module that many other modules use.  In that case, it's impractical to upgrade single modules, and a new version of synApps is needed.

 

Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

---

From: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> on behalf of Mark Rivers <rivers@cars.uchicago.edu>
Sent: Monday, February 5, 2018 5:59:30 PM
To: Jemian, Pete R.; tech-talk@aps.anl.gov
Subject: RE: AreaDetector repository inconsistent

 

> There is such a script for synApps (last updated in October 2017):
> https://github.com/EPICS-synApps/support/blob/master/assemble_synApps.sh

EPICS-synApps/support github.com APS BCDA synApps module: support

Right.  What I am suggesting is that there be multiple versions of that script

assemble_synApps_5_9.sh
assemble_synApps_5_10.sh
etc.

These are easy to create.  Testing should include making sure that everything compiles on Linux, vxWorks, Windows, OSX.  The APS Jenkins build server could do that.  It should also run some unit tests on modules that depend on others, etc.

Mark


> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On
> Behalf Of Pete Jemian
> Sent: Monday, February 05, 2018 5:52 PM
> To: tech-talk@aps.anl.gov
> Subject: Re: AreaDetector repository inconsistent
>
>
>
> On 2/5/2018 5:32 PM, Mark Rivers wrote:
> > In my opinion a new version of synApps should simply be a script:  It does a git clone
> and git checkout of the last tagged version of every module as of that date.
>
> There is such a script for synApps (last updated in October 2017):
> https://github.com/EPICS-synApps/support/blob/master/assemble_synApps.sh
>
> I used it today (making modifications for updated modules such as asyn
> and eliminating stuff I won't be using such as CAMAC) on a linux-x86_64
> host architecture.  As for areaDetector, I clone my own (instead of
> using the git submodule mechanism) using:
>
> wget
> https://raw.githubusercontent.com/EPICS-
> synApps/support/master/assemble_synApps.sh
> # edit for local choices
> bash assemble_synApps.sh
> cd synApps/support
> git clone https://github.com/areaDetector/areaDetector
> cd areaDetector
> git clone https://github.com/areaDetector/ADCore
> git clone https://github.com/areaDetector/ADSupport
> git clone https://github.com/areaDetector/ADSimDetector
>
> I do *not* want all that other detector driver support on my development
> system.  That system won't be using those modules anyway.
>
> Pete
>
> --
> ----------------------------------------------------------
> Pete R. Jemian, Ph.D.                 <jemian@anl.gov>
> Beam line Controls and Data Acquisition (BC, aka BCDA)
> Advanced Photon Source,    Argonne National Laboratory
> Argonne, IL  60439                    630 - 252 - 3189
> -----------------------------------------------------------
>        Education is the one thing for which people
>           are willing to pay yet not receive.
> -----------------------------------------------------------
>