Experimental Physics and
Industrial Control System

Mark Rivers <[email protected]> · Fri, 7 Sep 2012 14:53:54 +0000

Hi Angus,

You might consider the way it is done in synApps, which has 2 innovations that make handling configure/RELEASE files very nice.

The synApps directory tree is structured as follows:

support/configure/RELEASE
support/calc
support/motor
etc.

Typically the support/configure/RELEASE file is the single file that one edits to define the location of base and all synApps modules.  It contains lines like the following:

SUPPORT=/corvette/home/epics/devel
EPICS_BASE=/corvette/usr/local/epics/base-3.14.12.2
BUSY=$(SUPPORT)/busy-1-4
CALC=$(SUPPORT)/calc-2-10

After editing this file one types the following command at the top level in synApps, i.e. in the support/ directory

make release

This causes the support/configure/RELEASE file to be read, and updates all configure/RELEASE files in each synApps module to be consistent with support/configure/RELEASE.  Thus it modifies support/busy-1-4/configure/RELEASE, support/calc-2-10/configure/RELEASE, etc.  This makes it really simple to use absolute paths but without having to edit each module's configure/RELEASE file.

The second innovation is designed to address the following.  One wants to use a single working directory to build multiple architectures from different host computers, but where the paths to synApps and EPICS base are different.  The most common example is win32-x86, where the path needs to look like J:/epics/devel rather than /corvette/home/epics/devel, assuming J: is mapped to \\corvette\home.  

This is handled as follows.  The module configure/RELEASE files look like this:

SUPPORT=/corvette/home/epics/devel
-include $(TOP)/../configure/SUPPORT.$(EPICS_HOST_ARCH)
SSCAN=$(SUPPORT)/sscan-2-8-1
EPICS_BASE=/corvette/usr/local/epics/base-3.14.12.2
-include $(TOP)/../configure/EPICS_BASE.$(EPICS_HOST_ARCH)

Notice the lines that begin with "-include".  Those lines will optionally include support/configure/SUPPORT.$(EPICS_HOST_ARCH) and support/configure/EPICS_BASE.$(EPICS_HOST_ARCH) if those files exist.

In my case support/configure/SUPPORT.win32-x86 contains the following:
SUPPORT=J:/epics/devel

and support/configure/EPICS_BASE.win32-x86 contains the following:
EPICS_BASE=H:/epics/base-3.14.12.2

This allows a single synApps tree to be used with hosts that require different paths to base and support.

Mark





-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Angus Gratton
Sent: Friday, September 07, 2012 1:25 AM
To: [email protected]
Subject: EPICS build system, RELEASE file, and relative paths

Hi everyone,

I'm curious about how people manage paths in RELEASE, like EPICS_BASE,
ASYN, etc.

I've been using paths relative to the respective TOP, of this kind:

EPICS_BASE=$(TOP)/../../base

But when upgrading to 3.14.12.2 (from 3.14.11), convertRelease.pl
decided these were invalid (3 line patch attached that allows this by
canonicalising any path that exists at check time, any chance of this
please being accepted into base? )

The App Developer's Guide shows RELEASE with absolute paths
arranged under /home/epics, but surely this doesn't scale across
multiple developers or multiple working copies?

So it all made me wonder - how does everyone else do it?


- Angus


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);
 }



Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System