EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Best practices for introducing new dot releases of modules.
From: Ron Sluiter <[email protected]>
To: [email protected]
Cc: [email protected]
Date: Wed, 20 Feb 2013 13:44:21 -0600
Hello Murali,

Are you using synApps?

If so, skip down to "The way we handle this in synApps".  If not, read on...

The EPICS build system can check that all the specified support modules are consistent.
Support modules should have "CHECK_RELEASE = YES" in their <module>/configure/Makefile.
If you change a common support module like SNCSEQ, you have to change all the
<module>/configure/RELEASE files that contain SNCSEQ.  The errors are telling you
your system is inconsistent. You can't build a system with some modules using
seq-R2-0-11-lcls5 and others using seq-R2-0-11-lcls4 (of course you can, but who
knows what sort of problems you will inherit.).

1st you have to change all the <module>/configure/RELEASE files that contain
SNCSEQ_MODULE_VERSION = seq-R2-0-11-lcls4 to
seq-R2-0-11-lcls5.

2nd, do a "gnumake clean" is each of those support modules whose RELEASE file you
modified (if you don't you will probably get errors from the "dependency" files that
still have seq-R2-0-11-lcls4 in them).

Finally, you have to "rebuild all the other modules that the app depends on that also depend
on the sequencer".

The way we handle this in synApps, is that you change one file that specifies all the
support modules (<synApps>/support/configure/RELEASE) and execute  "gnumake release"
from the <synApps>/support directory. The "gnumake release" command updates all
the support modules' RELEASE files.  It is much easier.

Ron



On 2/20/2013 12:58 PM, Shankar, Murali wrote:

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. Allison, Stephanie
Next: RE: Best practices for introducing new dot releases of modules. Allison, Stephanie
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: Best practices for introducing new dot releases of modules. Allison, Stephanie
Next: RE: Best practices for introducing new dot releases of modules. Allison, Stephanie
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 20 Apr 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·