Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1367

News	FAQ
Search	Home

System generation

POSIX.2 compliance for make applies largely to the way makefiles themselves are written, and essentially restricts functionality to the lowest common denominator of all the many varieties of make. This means it would be it very difficult to write portable POSIX.2 compliant makefiles for AIPS++, so GNU make has been adopted instead. GNU make is itself POSIX.1 and POSIX.2 compliant, and so satisfies the ``POSIX compliance'' criteria originally set for AIPS++.

AIPS++ uses a hierarchical system of GNU makefiles. The head resides in ãips++/code and recursively invokes all makefiles residing in the subdirectories beneath it. The makefiles have the following features:

• The makefiles ``include'' architecture, site-, and possibly host-dependent makedefs files which allow local definitions to override the defaults, for example, architecture-specific libraries, the location of directories, compiler options, etc.

• The makefiles recognize that the AIPS++ installation may or may not have a copy of the rcs repositories. If the repositories are present, make automatically updates the plain-text copy if necessary. This should rarely be necessary though since ai keeps it up-to-date.

• The makefiles all contain a makefile target thereby causing GNU make to invoke its clever mechanism which ensures that makefiles remake themselves before attempting to remake anything else.

• Programmer workspaces are supported by means of GNU make's VPATH function. If the programmer has a .h or .C file in the current directory it will be used instead of those in the code areas. In this case the AIPS++ libraries and executables will not be updated. Instead, the preprocessed code, object module, and/or executable will be left in the programmer's own directory.

• The makefiles construct lists of dependency files via GNU make's wildcard function. Any .h or .C file in the relevant code directory (or rcs directory if present) is automatically included.

• Any subdirectory is recognized as a target. The allsys target of the makefile in the subdirectory is invoked. (This does not apply to include subdirectories which do not have makefiles but instead rely on the implement makefile for targets such as chkout).

• The implement makefiles know about the TESTBED mechanism by which class test programs are embedded within the class implementation files in an ``#ifdef TESTBED'' wrapper. Executables for the class test programs are handled by a pattern rule triggered by appending TEST to the class name.

• The diagnostic targets test_def and test_env can be invoked for informational and debugging purposes.

By allowing programmers to compile code in their own workspace without having to extract related files from the rcs repository, the makefiles minimize the number of files that need to be present in the programmer's own workspace. This reduces the possibility that these may be ``stale''.

The AIPS++ makefiles use a standard set of target names; references to a directory in the following list refers to the directory in which the makefile exists, or the corresponding AIPS++ directory:

• all (programmer): Remake all object modules, executables, etc. from files in the current directory.

• allsys (system): Remake all object modules, executables, etc. from files in the AIPS++ directory.

• clean (programmer): Delete ``rubbish'' files in the current directory.

• cleansys (system): Delete ``rubbish'' files in the AIPS++ directory.

• chkout (system): Update the AIPS++ code directories by checking out files from the rcs directory as required.

• makefile (general): Update the makefile itself by checking it out of the rcs directory, or (for programmers) copying it from the AIPS++ code directory.

• class.i (programmer): Preprocess class implementation file class.C (from the current directory if present) and leave it in the current directory.

• class.o (programmer): Recompile class implementation file class.C (from the current directory if present) and leave it in the current directory.

• classTEST (programmer): Recompile the class test program for class.C (from the current directory if present) and leave it in the current directory.

• lib(class.o) (system): Remake an object module class.o from class.C in the AIPS++ directory and replace it in the library

• lib (system): Remake the object library associated with an implement directory.

• ranlib (system): ranlib the object library.

• applic (progammer): Recompile application applic.C and leave it in the current directory.

• bin/applic (system): Recompile application applic.C in the AIPS++ directory and install it in the bin directory.

• bin (system): Recompile all applications in the AIPS++ directory.

• test_env (general): Print out all relevant make variables defined within the makefile.

• test_def (general): Print out all relevant make variables defined in the makedefs files included by the makefile.

Library maintenance requires special attention to avoiding conflicts which may arise when two programmers independently try to update the library. This is handled by a script used by the makefiles called updatelib. Object modules are deposited by make in a library-specific subdirectory of  aips++/$ARCH/$VERS/tmp, for example ...tmp/libkernel. When all modules have been produced the makefile invokes updatelib which copies the library to the temporary area, updates it, ranlibs it, then copies it back to the lib area.