Re: EPICS build system, RELEASE file, and relative paths

[Andrew Johnson <anj@aps.anl.gov>]

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