Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 6 Dec 2010 15:30:07 -0700

In order to consolidate redundant code in the ca client and server libraries
I am considering this organization for future releases

src/ca/client
src/ca/server

If we would like to keep the PCAS in base then we might also have this

src/ca/legacy/pcas
src/ca/legacy/gdd

Jeff
______________________________________________________
Jeffrey O. Hill           Email        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA

With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Davidsaver, Michael
> Sent: Monday, December 06, 2010 1:34 PM
> To: EPICS core-talk
> Subject: src/ reorganization
> 
> 
> Now that the Base repository is being tracked with a tool which
> understands renames I think that it is time to consider reorganizing the
> source tree.  To that end I would like to propose the following.  First,
> to change the directory structure to better reflect the different
> components in Base.  Second, to merge the many *Ioc libraries.
> 
> The first change could be made transparently to outside users.  The
> second will present problems for those not using $(EPICS_BASE_IOC_LIBS).
> But with 3.15 on the horizon this is the time for such things.
> 
> If we are going to do something like this it should be done early in the
> release cycle to minimize the impact.
> 
> = src/ reorganization
> 
> When I look at the src/ directory I see seven categories:
> 
> tools - Build system helpers
> 
> libCom - Things with no dependence on IOCs or CA
> 
> template - the make*App.pl scripts and templates
> 
> ioc - Everything related to PDB mechanics
> 
> std - Standard record definitions and soft device supports
> 
> ca - CA client library
> 
> cas - portable CA server
> 
> 
> == Dependencies
> 
> tools :
> libCom : tools
> template : tools
> ioc : ca tools
> std : ioc
> ca  : libCom
> cas : ca
> 
> And a diagram:
> 
> https://pubweb.bnl.gov/~mdavidsaver/files/base-reorg.png
> 
> The missing pieces here are dependencies from 'catools', 'cap5', and
> 'cas' on some header files from dbStatic including alarm.h.  This isn't
> a problem since everything is in one source tree, but perhaps there
> should be a module for common epics definitions?  Could this be part of
> libCom (ie 'libCom/epics/')?
> 
> 
> == Full list of renames
> 
> tools      = tools  (perhaps "buildtools"?)
> libCom     = libCom
> toolsComm  = libCom/tools
> as         = ioc/as
> bpt        = ioc/bpt
> db         = ioc/db
> dbStatic   = ioc/dbStatic
> dbtools    = ioc/dbtemplate
> misc       = ioc/misc
> registry   = ioc/registry
> rsrv       = ioc/rsrv
> RTEMS      = ioc/RTEMS
> vxWorks    = ioc/vxWorks
> dev        = std/dev
> rec        = std/rec
> softIoc    = std/softIoc
> ca         = ca
> cap5       = ca/perl
> catools    = ca/tools
> cas        = cas
> excas      = cas/ex
> gdd        = cas/gdd
> makeBaseApp= template/base
> makeBaseExt= template/ext
> util        (split up.  ca_test in ca/test, logserver in libCom/tools)
> 
> 
> 
> = Library mergers
> 
> >From what I can tell most of the *Ioc libraries can't really be used
> independently of one another.
> It seems to me that they fall into three groups.
> 
> dbBase = asIoc, dbIoc, dbStaticIoc, dbtoolsIoc, miscIoc, rsrvIoc,
> registryIoc
> 
>   The basic processing mechanisms which operate on dbCommon.
> 
> dbStd  = recIoc, softDevIoc, testDevIoc
> 
>   The standard recordtypes
> 
> dbHost = asHost, dbStaticHost
> 
>   Host tools like dbExpand use this
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System