Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 6 Dec 2010 18:17:29 -0600

Hi Michael,

On Monday 06 December 2010 14:34:15 Davidsaver, Michael wrote:
> 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.

Agreed, we can make these kinds of changes now while developing the 3.15 tree.

> If we are going to do something like this it should be done early in the
> release cycle to minimize the impact.

I agree, while a 'bzr merge' is able to follow changes through file moves, any 
related changes to the Makefiles will not be trivially mergable so we should 
try and get them in early.

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

Compare your ideas with my Unbundling (3.15/++) item on 
http://www.aps.anl.gov/epics/wiki/index.php/Future_Development_Ideas

> == 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/')?

I suspect it's just alarm.h and alarmString.h that need moving.  They should 
go somewhere like libCom/misc, although we might look at the number of libCom 
sub-directories and maybe consolidate some of them.  I suspect that having too 
many vpath directories to search for source files slows down the build 
somewhat.

> == Full list of renames
>
> tools      = tools  (perhaps "buildtools"?)
I prefer the current src/tools.  One of the first tasks of an apprentice was 
to make his own tools...

> libCom     = libCom
> toolsComm  = libCom/tools
> as         = ioc/as
We should split up src/as with the asDbLib files going to src/ioc/db and the 
asLib files to src/libCom/as.  The CA gateway uses asLib but shouldn't have to 
be linked against the rest of the IOC as it doesn't need it.  I think this 
split is clean and should be reasonably obvious to whoever does it.

> bpt        = ioc/bpt
> db         = ioc/db
> dbStatic   = ioc/dbStatic
> dbtools    = ioc/dbtemplate
> misc       = ioc/misc
> registry   = ioc/registry
> rsrv       = ioc/rsrv
> RTEMS      = ioc/RTEMS
Could the src/RTEMS files be moved into src/libCom?  That's where all of the 
other OS-specific source files are now found (or should be IMHO), and it lets 
people build other non-IOC applications on top of our OSI layer.

> vxWorks    = ioc/vxWorks
src/vxWorks no longer exists in the lp:epics-base (3.15) repository, it was a 
hold-over from the 3.13 compatibility code which I've already deleted.

> dev        = std/dev
> rec        = std/rec
> softIoc    = std/softIoc
> ca         = ca
> cas        = cas
> excas      = cas/ex
> gdd        = cas/gdd
I agree with Jeff about using src/ca/client and src/ca/legacy sub-directories.  
I'd suggest combining the src/cas/{generic,io/bsdSocket,generic/st} source 
directories into one src/ca/legacy/pcas though, and delete the parts of 
src/cas that we don't use any more.

> cap5       = ca/perl
> catools    = ca/tools
> 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
The testDevIoc library is device support for regression testing and can 
probably be moved out of Base into the lp:epics-base-test project.  That means 
the src/dev/softDev directory can become src/std/dev.

> dbHost = asHost, dbStaticHost
>   Host tools like dbExpand use this

See above for discussion about src/as.  dbStaticHost is being replaced by DBD 
file processing code written in Perl (which exists), so I think we could drop 
this library completely.  The new Perl code would become something like 
src/ioc/tools.

I approve of the overall idea, there are some details to work on though.

- Andrew
-- 
If a man is offered a fact which goes against his instincts, he will
scrutinize it closely, and unless the evidence is overwhelming, he will
refuse to believe it.  If, on the other hand, he is offered something
which affords a reason for acting in accordance to his instincts, he
will accept it even on the slightest evidence.  -- Bertrand Russell

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System