Version 1.9 Build 1556

News	FAQ
Search	Home

Next: Public interfaces Up: aips++ prototype Previous: User Interface

System management

With the dissemination of two papers, System management for aips++ - Part 1: organization and distribution and Part 2: activation, generation, and verification the design of aips++ system management is now well advanced. The final part of the trilogy Part 3: networking is scheduled for release by Jun/30, and will cover the area of network services.

Implementation of the system design has been driven by necessity. Creation of the empty aips++ directory tree was a trivial operation, belying a great deal of thought which had been put into its design.

Code management has, in the first instance, been implemented by using RCS. Each of the code directories has an RCS repository attached to it. Plain-text copies of the code are kept in the code area itself. Programmers can create their own "shadow" representation of the aips++ code directory tree by using the mktree utility which creates symbolic links to the ãips++ RCS directories. Programmers then appear to have their own private workspace with a window into the master RCS repositories, and can check code in and out of the RCS repository as though it were their own. This mechanism has served us extremely well.

A generic GNU makefile works together with the RCS mechanism described above to compile classes, class test programs, and the kernel library, and also has several other functions. With a dozen programmers contributing 1000 lines of code per day on average, the system has grown in complexity at an accelerating rate, and the makefile is now proving to be indispensible. The makefile allows programmers to compile code without having to check it out of RCS and thereby minimizes the number of files that need to be present in their private workspace, with the consequent possibility that these may be "stale". It uses the search path mechanisms which are part of GNU make, searching for files first in the programmer's own directory, then in the standard aips++ directories. However, although the makefile is logically correct, it is not particularly efficient in shirking unnecessary work. In particular, it recompiles a class implementation file if any header file has changed. A later generation should be able to do better.

aips++ programmers may now define their aips++ "environment" by means of an aipsinit.[c]sh script. This redefines the PATH (and MANPATH) environment variables, appending the aips++ binary (and man page) directories to it. It also defines a single environment variable, AIPSPATH, which contains five space-separated character strings which define the root of the aips++ directory tree, the host architecture, the aips++ version, the local site name, and the local host name. This information is fundamental and must be known in order to access the aipsrc databases.

The aipsrc databases have been implemented via a C-program called getrc. It looks for device and other definitions in a format similar to that of the .Xdefaults database used by X-windows. In resolving a reference it searches the following sequence of aipsrc files:

      ~/.aipsrc
      $AIPS/$ARCH/$VERS/$SITE/$HOST/aipsrc
      $AIPS/$ARCH/$VERS/$SITE/aipsrc
      $AIPS/$ARCH/$VERS//aipsrc

The last of these files contains default values, and the other three allow these to be overridden on a user-, host-, and site-specific basis.

The first use to which the aipsrc mechanism has been put is that of a simple, and easily configurable set of printer utilities, including a utility to print class header and implementation files in a compact and convenient form.

Next: Public interfaces Up: aips++ prototype Previous: User Interface Contents