Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 7 Dec 2010 14:58:58 -0700

While on the subject of reorganization, it would be nice to create separate
directories under configure/os for each one of the supported os if we
continue to roll our own build system...

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 Andrew Johnson
> Sent: Monday, December 06, 2010 5:17 PM
> To: [email protected]
> Subject: Re: src/ reorganization
> 
> 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