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
>
- References:
- Best practices for introducing new dot releases of modules. Shankar, Murali
- Navigate by Date:
- Prev:
Re: Best practices for introducing new dot releases of modules. Ron Sluiter
- Next:
Re: Best practices for introducing new dot releases of modules. Andrew Johnson
- 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: Best practices for introducing new dot releases of modules. Ron Sluiter
- Next:
Re: Best practices for introducing new dot releases of modules. Andrew Johnson
- 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
|