Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 874

News	FAQ
Search	Home

System directories

The AIPS++ system directory hierarchy is created in the first instance when AIPS++ is installed (see §2), and maintained thereafter by the sysdirs target which is invoked by allsys in the top level makefile (p).

Except for the aipsinit (p) files in $AIPSROOT, the AIPS++ system is completely self-contained within the architecture-specific subdirectory, referred to as $AIPSARCH (§1.2). In this context ``architecture'' should be interpreted to include variants in the operating system version and compiler.

In practical terms, the fact that the AIPS++ system does not rely on anything in the $AIPSCODE directories allows the source code to be deleted after the AIPS++ installation is complete in a production-line system.

At an AIPS++ development site with machines of several architectures where the source code must be retained, the strict separation of code from system provides for the $AIPSARCH tree to reside on a machine of the corresponding architecture without duplication of the code directories. With thoughtful unix filesystem management it also allows that the AIPS++ system for one architecture may remain available even if the server for any other architecture has crashed.

The system directories have the following structure:

         :             +---- lib ----+...
         :             +---- bin ----
         |             |
         |             +-- libdbg ---+...
         |             +-- bindbg ---
         |             |
         |             +-- bintest --
         |             |
         |             +-- libexec --
         |             |
         |             +---- aux ----
         |             +---- tmp ----+...
         |             |
         |             |             +--- info ----
/aips++ -+-- (arch1) --+---- doc ----+--- man1 ----
         |             |             +--- cat1 ----
         |             |             +---  :
         |             |
         |             |             +-- (host1) --
         |             +-- (site1) --+-- (host2) --
         |             |             +--   :
         |             |
         :             +-- (site2) --+...
         :             +---   :

The lib directory contains optimized static object libraries and possibly sharable objects. It sometimes also contains a subdirectory which serves as a C++ template repository. The bin directory contains AIPS++ system scripts and optimized applications. It is added to the PATH environment variable by the aipsinit (p) scripts.

The libdbg and bindbg directories contain debug versions of the libraries and executables. The bindbg directory is not usually populated but serves as the temporary residence for executables which are in the process of being debugged.

The bintest directory is used temporarily to store test executables and test results, and libexec contains scripts of various kinds which are not meant to be executed directly but are instead included by other scripts.

Files which are produced as intermediaries of system generation are cached in the aux directory. In particular, it includes dependency lists generated by the makefiles. Temporary storage is provided during a rebuild beneath the tmp directory. The structure and usage of the tmp directory hierarchy is soley the concern of the AIPS++ makefiles. It contains subdirectories specific to each AIPS++ package (see §1.1.1).

Online documentation is contained in the doc subdirectory. This includes unix manual pages and help files. The aipsinit (p) scripts add this directory to the MANPATH environment variable if it is defined at the time that aipsinit is invoked.

Finally, the $AIPSARCH directory contains site subdirectories which contain site-specific aipsrc and makedefs files (see §1.3), and possibly host-specific subdirectories which in turn contain host-specific aipsrc files. Multiple site-, and host-specific directories were provided to make it easier for a central site to administer AIPS++ for a collection of remote sites. If properly configured, it should allow a verbatim copy of the AIPS++ system at the central site to be downloaded at the remote site with only a minimum of reconfiguration required.