Experimental Physics and
Industrial Control System

"Davidsaver, Michael" <[email protected]> · Wed, 8 Dec 2010 10:28:11 -0500

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

The only significant difference is the separation between DB processing
mechanism, and standard record types.

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

Noted.

In the interest of not doing too much at once I'd like to do that this
in stages.  The first stage to be just moving whole directories.  The
second would be file moves.  Third would be merging the lib*Ioc
libraries.  The intent is that to ensure that things remain buildable
after each step.

Does this seem acceptable?

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

Yes I think so.  The application created only uses the IOC shell.

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

Noted

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

I understand this to be:

ca    = ca/client
cas   = ca/legacy/pcas
gdd   = ca/legacy/gdd
excas = ca/legacy/pcas/example

Is this correct?

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

So

src/dev/softDev = src/std/dev
src/dev/testDev = src/std/test  (pending removal)

Also, it was suggested to change the library names to libdbCore and
libdbRecStd.

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

Noted.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System