130 likes | 240 Views
Software Infrastructure LCLS Control SW Meeting, Mar 2, 2006. IOC Applications Host Applications Directory Structure Environment Setup Issues and To-Do. IOC Applications. Loads on top of RTEMS Apps built from many pieces Some pieces shared with other projects and sites
E N D
Software InfrastructureLCLS Control SW Meeting, Mar 2, 2006 • IOC Applications • Host Applications • Directory Structure • Environment Setup • Issues and To-Do
IOC Applications • Loads on top of RTEMS • Apps built from many pieces • Some pieces shared with other projects and sites • Some pieces shared between apps but not other projects • Other pieces are unique to the specific app • Sequences and DBs • Very special record, device, drivers • Test programs (ie, test some functionality on soft IOC or w/o EPICS) • What else App-Unique App-Shared IPAC SLC Restore Base RTEMS Apps RTEMS
IOC Applications (cont) • EPICS-version dependent • File I/O mostly on startup • Use small set of standard packages – rtems, gcc, perl, gnumake, snc, debugger • Collaboration development environment pretty mature • Not all pieces work for all target architectures (linux, beatnik, uC5282)
Host Applications • Usually large programs • Taylor to fit • Lots of file I/O • Not all EPICS-version dependent • Some require “exotic” packages • More system management needs Startup Options Env Vars Data Files Config Files
IOC and Host Applications • Source sometimes needs tweaks to meet site-unique requirements • rtemizing • adding more env vars and startup options for more flexibility • patches (ie, EPICS base) • File backup – AFS for source • Source control – CVS • Data output files - NFS
Reference Area Directory Structure • /afs/slac/g/lcls ($LCROOT) • 3.14.x.x-epics – epics version-dependent source • epics ($EPICS) – link to latest version of epics • tools ($TOOLS) – epics version-independent host tools, scripts, config files (except for large packages below) • xal ($XAL) – high-level physics apps and XAL “base” • cmlog $(CMLOG) – common message logger • matlab $(MAT) – xal and epics version-independent matlab scripts and config files maintained by controls
/afs/slac/g/lcls/epics – epics-version dependent • base - from APS • site – from other sites or developed here and shared, in general, only ioc code here (exception – SNC) • ioc – ioc apps and startup scripts • extensions – host tools, some executable scripts, NO ioc code here • *config – setup scripts (no executable scripts) • *edm – config files and displays • *other extension config files • * note – see issues later • base, site, extensions installed bin and lib areas in PATH and LD_LIBRARY_PATH
/afs/slac/g/lcls/epics/base, site, extensions Directories imported into CVS and then checked out: • configure – 3.14-style configuration files for gnumake • config – 3.13-style configuration files for gnumake (extensions-only) • src – top level directory of source for various packages Directories installed by gnumake: • bin – RTEMS loadable objects and host executable scripts and executables • lib – static and dynamic shared libraries • javalib – jar and java files (extensions only) • db, dbd – db, template, and db definition files (base and site only) • include – shared include files • doc and html – documentation (copy to wiki) • Only bin, lib, javalib, db, and dbd needed for running • base built for all targets • site built for subset of targets • extensions built for host target only
/afs/slac/g/lcls/epics/ioc – ioc apps and startup scripts • configure - build configuration files • <xxx>App – applications • iocBoot – startup files and ioc-related configuration files for iocConsole, dhcp, etc • installation directories (bin, db, dbd), expect very few files under include and lib • Only bin, db, dbd needed for running • Apps are target-dependent
/afs/slac/g/lcls/tools – epics-version independent Directories imported into CVS and then checked out: • vdct, archiveViewer, etc – so far, only java apps • script – executable scripts, included in PATH, all non-XAL java apps should have a script here, scripts to run extensions, etc, no non-exec setup scripts Directories created by build (or manually): • javalib – jar and java files • TBD • Only script and javalib needed for running • Some packages require manual copy of jar file from source area to javalib (unless build.xml is changed to do it) • Built for host target only.
Reference Area Comments • In general, CVS repository structure matches reference area • Once in production, reference area becomes read-only and is updated using only CVS • Add README file to each significant directory • Add Makefile at all levels, when possible • All non-exec setup scripts, config files, and standalone startup files go under a directory called “config” • All executable scripts go under “script” which is then added to PATH (exception – those that come with epics packages) • No data files in the reference area. Reference area is for source and installed files only.
Environment Setup • Right now, $EPICS/config/epicsReset.bash and .csh will reset any existing environment and set it to LCLS. Use epicsSetup.* if you don’t want PATH, etc, reset. • When a new extension or tool is added that needs env vars, add defaults to epicsSetup. If a tool requires many variables, create a config setup file and change epicsSetup to call it. • CLASSPATH is not set here – instead set using java option in exec script. • Nothing should be done in epicsSetup that changes a user’s home area (adds or removes files). Put that in the exec script.
Issues and To-Do • Some files under $EPICS are not epics-version independent and need to be moved out. • Environment setup files should allow selection of epics version with default being the one in production. • How to use the same RELEASE file for different EPICS versions. • Need plan for moving files to production. Also, plan for CVS branches. • Other production issues … • Better way to choose which site packages and which ioc apps are built for uC5282 too (or only). • Be nice if the shared NFS data area had a similar structure as the source area.