EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: RE: convertRelease.pl
From: "Jeff Hill" <[email protected]>
To: "'Mark Rivers'" <[email protected]>, "'Ralph Lange'" <[email protected]>, "'Steve Hunt'" <[email protected]>
Cc: "'EPICS Tech-Talk'" <[email protected]>
Date: Tue, 27 May 2003 09:36:03 -0600
Another possibility is to place your site specific overrides in
$(HOME)/configure/CONFIG.

Jeff

> -----Original Message-----
> From: Mark Rivers [mailto:[email protected]]
> Sent: Tuesday, May 27, 2003 6:34 AM
> To: Ralph Lange; Steve Hunt
> Cc: EPICS Tech-Talk
> Subject: RE: convertRelease.pl
> 
> 
> I understand Steve's concern about the hassle and potential for error of
> manually editing a dozen or more config/RELEASE or configure/RELEASE
> files each time you upgrade to a new version of an application on which
> other applications depend.  I also understand Ralph's concern about
> environment variables.
> 
> Ron Sluiter at the APS came up with a simple scheme that is a compromise
> between ease of use and safety.  He has a perl script that will update
> all of your config/RELEASE files for you based on  2 inputs: a list of
> all the applications that you want to update config/RELEASE files for,
> and a list of the locations of each application that you want to specify
> in those config/RELEASE files.  It simply searches for all strings in
> config/RELEASE of the form
> 
> EPICS_BASE=[old path]
> MPF=[old path]
> etc.
> 
> and sees if it knows about the items on the left hand side.  If so, it
> updates the values of [old path] on the right hand side to the current
> path for each item.
> 
> This is very convenient.  If I get a new release of MPF I just have to
> edit "master" file telling Ron's utility where the new version is
> located, then go to Ron's utility application and type:
> make release
> 
> It updates all applications that depend on MPF.
> 
> Why is this better than using environment variables, you ask?  Because
> the config/RELEASE files should be under source/release control.  Thus,
> just before installing the new version of MPF you should tag the current
> version of each application that depends on MPF, which you would
> normally want to do anyway.  That way if things don't work you can
> easily back out by knowing what config/RELEASE contained when things
> were stable.
> 
> I would argue that the manual edits mechanism can also lead to the
> unstable behavior that Ralph described.  The problem is that I install a
> new version of MPF and forget to edit one of the config/RELEASE files.
> Everything compiles and seems to work, but there is one small thing that
> has changed and some IOC will die on a holiday weekend. :-)
> 
> Mark


References:
RE: convertRelease.pl Mark Rivers

Navigate by Date:
Prev: RE: convertRelease.pl Mark Rivers
Next: R3.14.2 & excas Billy R. Adams
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  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: convertRelease.pl Mark Rivers
Next: R3.14.2 & excas Billy R. Adams
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·