Experimental Physics and
Industrial Control System

[email protected] (Marty Kraimer) · Tue, 13 Jun 1995 09:38:54 -0500

> From [email protected] Fri Jun  9 13:58 CDT 1995
> Date: Fri, 9 Jun 95 08:57:38 HST
> From: [email protected] (William Lupton)
> To: [email protected]
> Subject: Re: application directories and CVS, GNU make etc
> Content-Type> : > text> 
> Content-Length: 3246
p-level directory.
> 
>   I am very interested in your plans to do away with default.dctsdr
> (which I moved to a "data" installation directory because I couldn't
> bring myself to live with having installed files at the top-level). This
> would greatly simplify my plans for catting cat_ascii directories and
> the suchlike. Is there any way in which we can help here?
> 

Here are the main goals of this project.

1) Allow each database and ioc to use only the record types, device support,
   and drivers it actually needs. Thus even if applications and iocs share
   a common development tree each application/ioc can still use only
    the support it needs. 
2) Change dbStaticLib and iocCore so that it is possible to incrementally
   add record types, device support, driver support, and record instances.
   This is being done so that it will be possible to have on line add and
   delete and on line modification of links. Note that these features
   are not part of initial project but are necessary to add these features
   later.
3) Get rid of build utilities. Database Conf tools will get all info via
   ascii files. IOC will get info via combination of ascii files and code
   generated by same compiler that compiles other ioc code. This should
   remove all architecture dependent problems related to the fact that
   default.dctsdr is a binary file.

I can see how to do all of the above. I have already written some utilities that
accept old default.dctsdr files and generate the new ascii format files.
I have also started modifying dbStaticLib. I see no major problems in meeting
all of the above goals. In a few weeks there should be a document explaining
what is being proposed (Sorry. I have been having fun writing some code.
At least part of it was necessary so that I could convince myself that there
were no traps. At least that is my excuse for writing code before making
doc widely available)

In order to make this project really successful packaging is very important.
By this I mean "What will the users see". All Application Source/Release
environments will have to be modified. Here is an initial list of some
goals.

1) All record support, device support, and driver support should be unbundled.
   Thus users should only obtain the support they actually use. This applys
   to both database configuration tools and to what is loaded into iocs.

2) Users should easily be able to define the support they want. Ideally they
   would have a single file that looks something like the following:

    include "aiRecord.ascii"
    include "calcRecord.ascii"
    ...
    include "abDriver.ascii"
    ...

   If we can get to this point we should even be able to easily implement
   a tcl/tk based GUI interface for users to create the above file.

3) Must stay compatible with the database config tools users are currently
   using or intend to use. Note that minimal changes will be made to the
   existing static database access API (described in App Dev Guide). Thus if
   database config tools use that interface they can easily be changed to
   support new version of dbStaticLib.c. 

Some questions.
How do we get Source/Release to support this?
What should we do to base?
How do users add private record/device/driver support?
How do we handle makefiles so that they only build/link what is necessary? 

A lot of thought and help is needed to answer these questions.

>   I think that in the short term, Nick and I will continue to iterate
> and will document what we have done. Another major challenge of course
> is to handle the hooks to local conventions in a very neutral way. I
> tried to do that with my EPICS_APPLIC_INSTALL, EPICS_APPLIC_VERSION and
> EPICS_APPLIC_EXTERNAL variables.
> 

Again let me mention that a lot of thought and discussion went into the 
App Source/Release system at APS and that Johnny Tang looked at it hard before
making changes. Note that the currect version does support the new CONFIG
environment. It does not yet, however, support CVS. Thus it is no longer
necessary (and discouraged) to use imake. It is still necessary to use sccs.

Remember that an important goal should be to place EVERY user editable file
under S/R control.

>   If we are to move towards a single system then we all potentially have
> to compromise, so it would be useful to know what the major sticking
> points might be from your point of view. What are the sacred cows?
> 
This is a hard question. I dont think I can give a simple answer.

Marty Kraimer

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System