Experimental Physics and
Industrial Control System

"Allison, Stephanie" <[email protected]> · Wed, 20 Feb 2013 11:48:34 -0800

Hi Murali,

I didn't answer your question:

> So, to test a dot release of the sequencer, should I rebuild all the other modules that the
> app depends on that also depend on the sequencer?

You should.  But you need to keep module dependencies on other modules down to as minimal as possible.  So if you download a module and it needs other modules just to build some test image and you never plan to use that test image, that don't build it and remove the other modules from RELEASE.

Also, for simple and small modules that all require another module (like asyn), I group them and make a module of modules, all sharing the same RELEASE.   So when I upgrade to a new asyn, I only have to retag and rebuild one module in addition to the new asyn.  Sort of like synApps, I guess.

Stephanie

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Shankar, Murali
> Sent: Wednesday, February 20, 2013 10:58 AM
> To: [email protected]
> Subject: Best practices for introducing new dot releases of modules.
> 
> Hello all,
> 
>   I have a noobie EPICS build system question. What I am actually trying to do is to figure
> out how to introduce a new version of a module (for example, the sequencer, as it is
> widely used) with a minor bug fix. My users do not want me to patch in place; so I take
> seq-R2-0-11-lcls4  and create a new dot release of the sequencer - for example, seq-R2-0-
> 11-lcls5. I change the IOC application to use the new version of the module. However,
> when I try to build it, I get
> 
> Definition of SNCSEQ_MODULE_VERSION conflicts with ASYN support.
> In this application a RELEASE file defines
>                 SNCSEQ_MODULE_VERSION = seq-R2-0-11-lcls5
> but ASYN at /afs/slac/g/lcls/epics/modules/R3-14-12/asyn/asyn-R4-17-RC1-lcls1 defines
>                 SNCSEQ_MODULE_VERSION = seq-R2-0-11-lcls4
> Definition of SNCSEQ conflicts with ASYN support.
> In this application a RELEASE file defines
>                 SNCSEQ = /afs/slac/g/lcls/epics/modules/R3-14-12/seq/seq-R2-0-11-lcls5
> but ASYN at /afs/slac/g/lcls/epics/modules/R3-14-12/asyn/asyn-R4-17-RC1-lcls1 defines
>                 SNCSEQ = /afs/slac/g/lcls/epics/modules/R3-14-12/seq/seq-R2-0-11-lcls4
> Definition of SNCSEQ conflicts with MOTOR support.
> In this application a RELEASE file defines
>                 SNCSEQ = /afs/slac/g/lcls/epics/modules/R3-14-12/seq/seq-R2-0-11-lcls5
> but MOTOR at /afs/slac/g/lcls/epics/modules/R3-14-12/motor/motor-R6-6-RC2-lcls1
> defines
>                 SNCSEQ = /afs/slac/g/lcls/epics/modules/R3-14-12/seq/seq-R2-0-11-lcls4
> 
> 
> So, to test a dot release of the sequencer, should I rebuild all the other modules that the
> app depends on that also depend on the sequencer? We do maintain a shared repository of
> modules; so perhaps that's the issue. Are there standard techniques people use to introduce
> new versions of modules?
> 
> Any help is appreciated.
> 
> Regards,
> Murali
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System