EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: living without soft links
From: [email protected] (Ralph Lange)
To: [email protected] (Tim Mooney)
Cc: [email protected] (EPICS Tech-Talk)
Date: Thu, 10 Dec 1998 17:49:19 +0100 (MET)
> 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.

Right. Actually there has been a change somewhere between beta4 and beta11:
Formerly all files in database format (containing $() or fully resolved)
were called .db and the files containing the substitution lines for
database instantiation were called .template. I think this naming
convention was definitely misleading and caused severe problems when
designing convenient make rules.

> In fact, there's really no way to tell whether a file is a template or
> a db except to look at its name.

This is why the naming convention was changed to be more obvious.

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

The substitutions files (as they are database sources) do not belong in the
iocxxx directory. Make will install substitutions files into the $TOP/db
directory, which is where all database related files are installed.

Again: Please read the paragraph about the <top>/xxxApp/xxxDb/Makefile.Host
in the "Description of Makefiles" section of the "EPICS IOC Applications
Building and Source Release Control" document, which contains a more
detailed description of how to create database files using the beta12 make
rules. These rules are powerful and easy to use once you decide to follow
the (minimal) conventions you have to obey.

> I've never had the pleasure of expanding a template at build time, but it
> must be intense. ;-)

I would _strongly_ suggest expanding databases at build time:
 o It is easier to find unresolved macros --- before the IOC is rebooted.
 o The IOC will load an expanded database with dbLoadRecords() faster than
   expanding it at load time with dbLoadTemplate(). dbLoadTemplate() calls
   dbLoadRecords() for each instance, i.e. the template database file will
   be read many times. The overhead will be at least calls to open() and
   close() for every line in the substitutions file. This overhead will be
   small when using NFS, but is noticable with ftp/rsh access.
   (On one of our "packed" IOCS that uses several hundred instantiations of
   database templates: 2.5 min with NFS compared to 14 min. using rsh
   access.)

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

Try changing line 46 in RULES.Db:
< $(notdir $(TEMPLATE_LINKS)): %.template:
> $(notdir $(TEMPLATE_LINKS)): %:

This should make the link/copy mechanism of USES_TEMPLATE work for any file
name. Please tell me if this works, for it might be considered a permanent
change then.

>  I think I'll give Marty's suggestion (add an argument without changing
>  the order of arguments) a try.

The change mentioned above might be less work ;-)

> > I would prefer if one could give dbLoadRecords() and dbLoadTemplate() a set
> > of include paths [...]
> 
> 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.

This is true only for "relative" cd commands. I don't see any problem when
using absolute path names. At BESSY we are using an application that
creates all the st.cmd files (and the libraries) for an arbitrary number of
IOCs. This application uses full path cd commands in all appropriate
places. We don't edit st.cmd files. Well ... almost never.

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

I don't get the point here.
You can always change the st.cmd to make an IOC load other databases from
other places. You will always have to go to the database directory if you
want to change the database itself.
I think having different versions of databases with the same name in
different places is an approach that will lead to confusion and lots of
errors that are hard to track down. Yuck. Don't do it.

Hope this helps,
Ralph

References:
Re: living without soft links Tim Mooney

Navigate by Date:
Prev: Re: Monitors on a stringin record Ralph Lange
Next: Links between IOCs Hammonds, John
Index: 1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: living without soft links Tim Mooney
Next: Re: living without soft links Tim Mooney
Index: 1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·