living without soft links

[mooney@aps.anl.gov (Tim Mooney)]

Dear folks,

The mechanisms in 3.13.1 for getting along without soft links (mostly
"cdCommands") are making a bit of a mess in applications I've ported
from 3.13.0.beta11.  I'm wondering whether I've been operating from the
wrong idea of how a share tree should be used, and whether I really
understand how the make rules operating in xxxApp/Db are intended to
work.  I also have a reasonably simple solution that works for unix
path names, though I haven't tried it with NT.

First I want to make real sure nobody reads this as a complaint.  It is
astonishing how easily our applications have ported from 3.13.0 to
3.13.1, given the changes in underlying code and in the build.  I'm not
using NT just now, but I really like the idea that I could (and I
especially like the idea that somebody else did all the work).

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 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.  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.)  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.)

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.  You
end up with "cd" commands all over the place, and you can't modify or
move things without paying close attention.  I never pay close
attention to anything, so this is a problem for me.  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.  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.

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".

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.

-----------------------------------------------------------------------
1) Modify dbLoadRecords() and dbLoadTemplate().  (The modified versions
I'm using blindly assume directories are separated by "/" in path
specifications.)

int dbLoadRecords(char *path, char *db_file, char *pattern);
                  ^--added--^
int dbLoadTemplate(char *sub_file, char *path_to_template);
                                 ^--------added---------^

2) Add code to xxxApp/config/makeIocCdCommands.pl so that it writes
top = <full path to application top>

3) In st.cmd, instead of

	cd share
	dbLoadRecords("stdApp/Db/database1.db", "...")
	cd startup
	dbLoadRecords("../../Db/database2.db", "...")
	dbLoadTemplate("motor.substitutions")
	# first line of the sub file is "file ../../db/motor.template",
	# and that file has been copied from share by gnumake

write

	dbLoadRecords(share,"stdApp/Db/database.db", "...")
	dbLoadRecords(top,"xxxApp/Db/database.db", "...")
	dbLoadTemplate("motor.substitutions",share)
	# first line of the sub file is "file stdApp/Db/motor.template",
	# and that file is in the share directory

-----------------------------------------------------------------------

Any comments?  

Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab