Much of what ST developers need to know is shared with LAT developers. So most of the standard how-to-index is appropriate. A brief summary of the main points
The anatomy of a package on disk follows: (in cvs the intermediate <version> folder is not present). <package> represents the package name.
| <package>/ <version>/ cmt/ <package>/ doc/ src/ test/ <application>/ pfiles/ $CMTCONFIG |
Top level, in a folder in the CMTPATH version identifier, which corresponds to a cvs tag, for example v1r3p4 contains the requirements file, with use statements for packages it depends on any interface header files must be here, in the <package> namespace must contain the release.notes files, any other documentation all source (and required mainpage.h) should be under here: top level has library classes. unit test code: application is named test_<package> optional application code, one folder per application location of parameter files required by applications or tests Location of binaries, created by running gmake in the cmt folder |
There are at least 5 categories of packages:
- checkout
- Contain no code, the requirements file refers to an explicit set of package/version combinations. Used to define a coherent set. Within ST we have IExternal and ScienceTools, with the tag of the latter defining a release. All other packages must have full or partial wildcards in their use statements
- interface
- Also has no code, used to refer to external code. All are in the IExternal path. The full list is: cfitsio, CLHEP, pil, python, ROOT, XMLEXT.
- policy
- Defines macros and patterns for use by code packages. We have STpolicy which adds ST-specific policies to GlastPolicy.
- library/application
- Contains C++ code that is made available for linking by other packages. It must have a unit test, and may also define applications or tools. Examples are map_tools and Likelihood. There are specific patterns for either, described below.
- user interface
- The top-level package that provides a user environment, perhaps a GUI. See sane.
Another type corresponds to what I generate for my analysis. It is private, containing development code, and
In fact the set of packages defined by a checkout package is not necessarily the same as the set that is "tracked". This list can be found in the cvs package ReleaseManager, here. Both lists can be modified by a user knowing the magic user/password combination, here
This package type is the only one that most developers will be concerned with. The basic elements and useful utilities are
| package st_demo version v0 author J. Doe <johndoe@u.edu> # RM will notify you #for standard environment, patterns, executable use STpolicy * use st_app * # makes a library that client packages can access, and a test program apply_pattern ST_library option=-no_share # not using shareables now # add our pfiles to the global list apply_pattern ST_pfiles # create an appliation that will be identifed to clients in the ST_apps env var apply_pattern ST_app name=demo |
It is illustrated by a minimal, but complete package example, see users/burnett/st_demo.
Of most tools with require I/O to FITS files, and optionally read from ROOT tables.
The following diagram shows use relationships for the current standard analysis environment, which is defined by the packages that sane uses. (The name "sane" is inspired by that phrase. Or perhaps "science" instead of "standard".) It uses only packages that provide tool executables, shown in gray. At the bottom row are the interface packages as ovals, the STpolicy policy package, and facilities for low-level utilities. Since astro, xml, and facilities are shared with the LAT code, they do not use STpolicy. Note that map_tools shows that it provides services to Likelihood, as well as defining tool executables.
The package sane provides a simple executable (sane) that runs a very simple python script to generate an application tool bar. Running it pops up the following:
Clicking any of the buttons starts the corresponding executable.
Note that this is a preliminary demonstration that exercises the basic architecture and interface. With the flexibility and GUI capability of python/Tk, much more elaborate and useful interfaces, like Jim's likeGui which inspired this, will be coming soon. Of course, for those who wish it, all applications will be accessible by name in a shell.
See the previous dependency plot. Recall that we are removing Goodi and redesigning packages that depend on it.
The first step, introduction of a new I/O package and definition of a basic tool organization, is complete. Current packages that need to be updated to use STpolicy, st_app, and tip are:
All the packages specified by the current ScienceTools HEAD can be downloaded with the command
cmt co -R ScienceTools
You can get the two example packages by
cmt co -o users/peachey st_app_examples
cmt co -o users/burnett st_demo
Last Update: 08/04/2004 15:42 -0700
T. Burnett / J. Peachey