> A primary goal of the new way of handling the database definitions is that
> ascii files work the same on both the development platforms and on vxWorks.
> This lead to the decision NOT to use the c preprocessor.
Yes, I agree, it's a compromise, and I think you probably made the right
decision.
> Another goal was quick loading of ascii files. Thus the path mechanism is
> not as general as that supported by the c preprocessor, i.e. the rules
> always determine a unique place to locate an include file. The rules
> work very well on Unix (less than 1 second to load all menus, record types,
> devices, and drivers supplied with base). On vxWorks if NFS is used performance
> is still acceptable. If NFS is not used then there is about a 2 second
> overhead for every file opened. This is not acceptable (> 2 minutes to load).
> This is the only reason for dbExpandAscii.
Yes, but these times would be about the same if you had a search path
mechanism since I believe all the files in base are actually in one
directory which, (if you were sensible) would be the first in the path.
> A last goal that we have always had for Application S/R systems is to allow
> developers to simultaneously work on applications using different epics
> releases. That is why getrel creates soft links to base, etc. The App S/R
> systems in turn create soft links to base in any sub directories necessary.
> dbExpandAscii assumed the same model. The only other method I can think of
> is to use environment variables to define things such as base. This
> would mean that the application developer has to continually change the
> vales of the environment variables whenever he/she moves between applications.
UAE does this slightly differently. First of all it doesn't use getrel.
There are soft links so the user can set his path to scan down them
(and hence satisfy your different epics releases concern), but there
are no links directly to the base directory in the source tree. Also,
the build process does not use the soft links - it uses Make variables
which are defined in a configuration file (like Epics base does).
It also makes a point of ensuring that the application directories are
pretty much position independent so the directory structure is left up
to the individual site. This enables me to send you a tar file of my
xyz driver and you can unpack it where you want to and it should make
cleanly.
> As regards to using # as the comment character. This is what is used by
> most shells (csh sh ksh bash)...
As I said, fine...
> One additional comment. Jeff Hill pointed out that using the word ascii
> everywhere is not a good idea. I am going to change things so that .db is the
> normal extension for all database related files. I also want to combine
> dbLoadAscii and dbLoadRecords into one utility called dbLoadDatabase. The
> word ascii will probably disappear everywhere.
Fine...
Back on my soap box...
Overall, I feel that the justification for the path mechanism is not
terribly strong and would prefer it to be a more normal search path
one (for both VxWorks and Unix). My reasoning is:
1. I don't like having path information that enforces a particular
directory structure embedded in files (especially when I use a slightly
different structure), and (to a lesser extent) that I have to be in
a particular directory before I can execute a command. I feel this
could make the files more difficult to maintain and transfer between sites.
2. Most of the Epics ascii (db) files tend to cluster in a very few
directories with the vast majority of them in one. Thus, as long as the
search path is in the right order efficiency probably won't be affected
too much.
3. On VxWorks the database could be loaded incrementally with a different
search path each time. Typically you could forsee loading the record
device and driver definitions separately from the actual database info.
4. You can always use dbExpandAscii. This would be fully done via a make rule
and so would be fairly transparent and since it was running on Unix it
would be fast. (A hell of a lot faster than makesdr at the moment).
5. I don't like having a mechanism called `path' which is different to all
other path mechanisms. This is both confusing and goes against the
experience we have built up with the existing path mechanisms which seem
to work well and are very flexible.
As a suggestion for debate is that:
1. A search path list can be be specified by some mechanism for all database
loading tools on both VxWorks and Unix.
2. There be an implicit entry at the end of the search path list which is the
directory in which the current file being scanned resides. If you want the
current directory in the search path you have to add . to it.
The latter allows us to use the all.ascii directly from the base
distribution (and other summary files from other directories) and would
remove the necessity for any path commands in the base release.
The following are suggestions for various means of specifying the path
mechanism.
1. As a parameter to the various commands. (On VxWorks the commands may
only have a single string parameter which had embedded spaces and this
string would be parsed to form an equivalent of argc and argv).
2. As an environment variable, with paths delimited by colons.
3. As a command in the files, with paths delimited by colons.
In the best of all possible worlds you could have all three mechainisms
(but I am not doing the coding) with, probably, the first overriding
the second which overrides the third (as in makefiles). It probably
wouldn't be too hard to dream up a simple substitution mechanism (i.e.
use a plus sign to represent the existing, colon delimited, path
string) which could almost reproduce the current mechanism.
Finally I should say that I welcome people other than Marty to comment
since diverse views may help. If you all shout me down I'll shut up
gracefully. I also don't any of the history behind this decision or
even whether it is used by medm and so can't be changed without causing
a great deal of users a great deal of strife (another command line
flag?). Thus, if there are these historical I would be interested in
hearing that too.
Comments?
Nick Rees
Joint Astronomy Centre Ph: +1 (808) 961-3756
660 N. Aohoku Place Fax: +1 (808) 961-6516
Hilo, HI. 96720 Internet: [email protected]
- Navigate by Date:
- Prev:
Returned mail: Cannot send message for 1 hour Marty Kraimer
- Next:
Re: Ascii databases Marty Kraimer
- Index:
1994
1995
<1996>
1997
1998
1999
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: Ascii databases Marty Kraimer
- Next:
Re: Ascii databases Marty Kraimer
- Index:
1994
1995
<1996>
1997
1998
1999
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
|