Experimental Physics and
Industrial Control System

[email protected] (Ralph Lange) · Tue, 8 Dec 1998 16:15:04 +0100 (MET)

Well,

some thoughts (as I feel kind of addressed by this):

> Now let me describe how we're using share, and applications inheriting
> from share, in case that's what really needs fixing.  Our share
> directory contains record and device support, databases (.db files),
> and display files.  Our application directories make and install their
> own copies of object files built from source code in share, but they
> use databases and display files directly from share, without any
> isolating make or install process.

This matches exactly my understanding of how share is suggested to be used.

> (This never was all that great, because changes to display files take
> effect immediately, changes to databases take effect when crates reboot,
> and changes to source code take effect only after applications are
> rebuilt and crates reboot.

Agreed. OTOH, I don't see a real solution for that, since this is true even
for a fully self-contained application. Generally when using compilers you
will have to rebuild any application before changes to source code will
take effect. ;-)

> I do understand that share is intended to be a release, rather than a
> work in progress, but if we made a new release of share for every minor
> change we'd be swimming in them, and there's no way to thoroughly test a
> lot of our stuff without putting it into service.)

This is correct. Share is intended to be a released system itself. So there
is a separate share directory for each combination of share release and
base release. If you decide to follow every minor base release, you will
end up having LOTS of different share directories. This ... well ... is not
an optimal situation.

> The share tree and a sample application tree get tarred up and put on the
> web so anyone who cares to can download them, edit config files, build,
> and in the simplest case run after modifying st.cmd, the substitution
> files, and the autosave files.  (In practice, CAT-specific stuff gets
> added to share and beamline-specific stuff gets added to applications.
> It's a huge benefit for this customization process to be as simple and
> transparent as possible.)

I agree that this should be possible.

> One problem under 3.13.1 is that st.cmd is difficult to maintain when
> some databases come from share and some come from the application.

I don't see a useful way to share db (*.db) files. IMO share should hold
the database templates (*.template), whereas the application uses this
shared template with its own substitutions file (*.substitutions).

> Loading databases
> from templates is a more serious problem:  we keep application-specific
> substitution files in the application tree and expand templates at boot
> time. But a local substitution file cannot expand a database from
> share unless the sub file contains the full path to that database--a
> really bad thing to do, I'd argue.

Wrong. The make rules definitely support local substitutions files and
shared templates.

> So the template must first be copied into xxx/db by the make rules, which
> seems a useless pain in the neck, and database files are insulated or not
> insulated from changes in share depending on whether you load them with
> dbLoadRecords() or via dbLoadTemplate(), which means I'm going to get
> phone calls.

The make rules will use soft links to the share/db directory on unix
systems and copy the shared templates to the application under WIN32.

> Ideally, I suppose, all databases from share should be copied into
> applications, but I can't get the make rules to copy files whose names
> end with ".db" (I get the error message "No rule to make target <path>/
> <name>.db-stamp"), though I can make them copy files ending in
> ".template".

This is because ".db" is used for "blown up" (expanded) databases whereas
template files are expected to be called ".template" and substitutions
files to be called ".substitutions". (Sorry if this is not obvious enough.)

Setting the USES_TEMPLATE make variable (in the Db Makefile.Host) to hold
the names of all external templates, i.e. those from share or other
structures, should result in links being set up for those templates
(i.e. copies under WIN32) and succesful database generation.

All databases that are intended to be loaded by an IOC are installed in the
$(TOP)/db directory. It is not suggested to load the databases from the
source tree (i.e. from $(TOP)/xxxApp/Db).

Please refer to the "Description of Makefiles" section of the "EPICS IOC
Applications Building and Source Release Control" manual (June 15 version)
for a complete description of these mechanisms.

> Anyway, here's a solution that makes porting from 3.13.0.beta11 to
> 3.13.0.beta12 a whole lot easier for me, and that doesn't cause
> maintenance problems in the ioc directory.
> [...]

This seems to be a working solution.

Anyway, I don't like both dbLoadRecords() and dbLoadTemplate() calls being
changed. This will make all older startup scripts non-functional.

I would prefer if one could give dbLoadRecords() and dbLoadTemplate() a set
of include paths that are searched when opening a file. (Much like the dbExpand
tool that already is using include paths.) The routines could check for an
environment variable that may contain a colon separated list of paths. (To
be set in the startup file.)

This solution would make the calls still compatible and serve for all your
needs.

How about this?
Ralph
-- 
      __  Ralph Lange                         Email:       [email protected]
     /\ \                                     WWW: http://www.bessy.de/~lange
    /  \ \  BESSY II                          
   / /\ \ \  Berliner Elektronenspeicherring- Snail:                 BESSY II
  / / /\ \ \  Gesellschaft fuer Synchrotron-               Rudower Chaussee 5
 / / /__\_\ \  strahlung m.b.H.                       D-12489 Berlin, Germany
/ / /________\                                Phone:         +49 30 6392-4862
\/___________/ Control System Group           Fax:                ...   -4859

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System