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  <20122013  2014  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  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: EPICS build system, RELEASE file, and relative paths
From: Andrew Johnson <[email protected]>
To: [email protected]
Date: Fri, 7 Sep 2012 10:47:48 -0500
Hi Angus,

On 2012-09-07 Angus Gratton wrote:
> I'm curious about how people manage paths in RELEASE, like EPICS_BASE,
> ASYN, etc.
...
> So it all made me wonder - how does everyone else do it?

As a contrast to Mark Rivers post about how synApps manages versions which is 
good for experimental installations, the approach we use for the Accelerator 
systems here at APS is better suited to an installation with the more formal 
approach to change control that is called for to provide highly reliable 24×7 
machine operation.

We use absolute paths, with intermediate variables to remove duplication, 
something like this:

SUPPORT = /home/epics/3.14.12.2
ASYN = $(SUPPORT)/modules/soft/asyn/4-19-aps2
EPICS_BASE = $(SUPPORT)/base/3-14-12-2-aps1

This is for installation of modules and IOCs in the shared (NFS-mounted) 
production area which is under change control.  Note that the full path to 
Asyn is /home/epics/3.14.12.2/modules/soft/asyn/4-19-aps2 so all modules 
including Base itself are built in an area that is specific to the version of 
Base (3.14.12.2), and we have a local -aps<n> version number on the end so we 
can have multiple local versions of the same module release installed.

We have a rule that we *never* modify or rebuild a module installed in the 
production area once a production IOC has been built using that version.  If 
we need to fix problems with the code we build a new local version containing 
that bug fix which has an incremented -aps version number.

We also increment the -aps<n> version number when we install a new version of 
say Asyn that have other modules downstream that rely on it, say modbus.  We 
might have modules/plc/modbus/2-3-aps1 built using modules/soft/asyn/4-18-aps1 
and modules/plc/modbus/2-3-aps2 built using modules/soft/asyn/4-19-aps1; the 
only difference between the source code of those two modbus versions is the 
ASYN line in their configure/RELEASE files.  This way we can never break any 
production IOCs when we install new versions of support modules, because the 
person responsible for editing an IOC's RELEASE file is the engineer in charge 
of the IOC area and if she doesn't change it the IOC will continue to use the 
old version.

A developer who is updating an IOC or working on a new version of a support 
module will want to use as many of the production-built modules as possible 
during development, but if there's a new version say of Asyn that he needs he 
may have a local copy of that built under his home directory, and will change 
the ASYN pointer in his IOC to use that version instead while he's working on 
it:

SUPPORT = /home/epics/3.14.12.2
#ASYN = $(SUPPORT)/modules/soft/asyn/4-20-aps1
ASYN = /home/anj/modules/soft/asyn/4-20
EPICS_BASE = $(SUPPORT)/base/3-14-12-2-aps1

He shouldn't commit that RELEASE file change to CVS though because production 
builds should never refer to non-production modules, so he'll request that 
Asyn version 4-20 be built (as version 4-20-aps1) in the production 3.14.12.2 
area and point his RELEASE file to that before he can commit and have his IOC 
built in production.

HTH.

As to your patch, it looks reasonable, but I wonder what abs_path() is doing 
that rel2abs() isn't?  Is it working around an automounter issue, or are you 
using soft links?

> Index: base/src/tools/EPICS/Path.pm
> ===================================================================
> --- base/src/tools/EPICS/Path.pm        (revision 1268)
> +++ base/src/tools/EPICS/Path.pm        (revision 1269)
> @@ -123,6 +123,9 @@
> 
>      # Now calculate the absolute path
>      my $abs = File::Spec->rel2abs($path, abs_path($cwd));
> +    if (-e $abs) {
> +        $abs = abs_path($abs);
> +    }
> 
>      return LocalPath($abs);
>  }

- Andrew
-- 
Never interrupt your enemy when he is making a mistake.
-- Napoleon Bonaparte


Replies:
Re: EPICS build system, RELEASE file, and relative paths Angus Gratton
References:
EPICS build system, RELEASE file, and relative paths Angus Gratton

Navigate by Date:
Prev: sequencer release 2.1.10 Benjamin Franksen
Next: Re: Epics driver using BLT or CBLT to read FIFO wanted Michael Davidsaver
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: RE: EPICS build system, RELEASE file, and relative paths Mark Rivers
Next: Re: EPICS build system, RELEASE file, and relative paths Angus Gratton
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·