Re: living without soft links

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

re...

> some thoughts (as I feel kind of addressed by this):
> [...]

Thanks for replying.  I didn't want to single you out because I don't
know how the decisions on the new build system were made, and also
because I was hoping for a general idea of how people are using share.

I think I see the picture you're working from: The make rules assume
share will supply templates but not db files to applications, and the
underlying assumption is that db files are fully resolved--i.e., they
contain no $() variables.  But I don't know how widespread that
assumption can be, because most (all?) database configuration tools can
produce db files containing $() variables, and dbLoadRecords supports
them.

In fact, there's really no way to tell whether a file is a template or
a db except to look at its name.  None of our db files are fully
resolved; we expand them at boot time--with dbLoadRecords if only a few
instances are needed, or with dbLoadTemplate if enough instances are
needed to justify the hassle of maintaining a substitution file in the
iocxxx directory.  I've never had the pleasure of expanding a template
at build time, but it must be intense. ;-)

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

It might be nice to have similar treatment for db files.  I'm trying to
decide whether this would be preferable to modifying (or writing an
alternate version of) dbLoad*.  I think I'll give Marty's suggestion
(add an argument without changing the order of arguments) a try.

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

I like the fact that a path would leave dbLoad* calls untouched, but
syntactically it's not much different from cd, and cd causes problems
in st.cmd because its effect is not local.  It's very nice to be able
to load a new version of a particular database into a particular crate,
and later roll back to the standard version, with a local modification
in st.cmd--where the next guy who works on the system will see it
immediately, and where you can leave a comment.  If you have to go into
<top>/db, or <top>/xxxApp/Db, to do/undo this, you're kind of setting a
trap for the next guy to fall into.


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