RE: Best practices for introducing new dot releases of modules.

["Allison, Stephanie" <saa@slac.stanford.edu>]

Hi Murali,

When I download a module that requires SNCSEQ (like asyn) and I don't plan to use the sequence that comes with that module (which is usually true in my case), I remove the SNCSEQ dependency from the RELEASE file of that module and comment out any reference to the sequence (if necessary).  Sometimes, a module is smart enough to know not to build the sequence if SNCSEQ is not defined. 

Stephanie Allison

> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf
> Of Shankar, Murali
> Sent: Wednesday, February 20, 2013 10:58 AM
> To: tech-talk@aps.anl.gov
> 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
>