VMS/IRAF Installation and Site Manager's Guide

• Edit one or more source files.
• Use mkpkg to compile any modified files, or files which include a modified file, and relink the package executable.
• Test the new executable.

The mkpkg file for a package can be written to do anything, but by convention the following commands are usually provided.

mkpkg

Same as mkpkg relink below.

mkpkg libpkg.a

Updates the package library, compiling any files which have been modified or which reference include files which have been modified. Private package libraries are intentionally given the generic name libpkg.a to symbolize that they are private to the package.

mkpkg relink

Rebuilds the package executable, i.e., updates the package library and relinks the package executable. By convention, this is the file xx_foo.e in the package directory, where foo is the package name.

mkpkg install

Installs the package executable, i.e., renames the xx_foo.e file to x_foo.e in the global BIN directory for the system to which the package foo belongs.

mkpkg update

Does everything, i.e., a relink followed by an install.

If one wishes to test the new program before installing it one should do a relink (i.e., merely type "mkpkg" since that defaults to relink), then run the host system debugger on the resultant executable. The process is debugged standalone, running the task by typing its name into the standalone process interpreter. The CL task dparam is useful for dumping a task's parameters to a text file to avoid having to answer innumerable parameter queries during process execution. If the new program is to be tested under the CL before installation, a task statement can be interactively typed into the CL to cause the CL to run the "xx_" version of the package executable, rather than the old installed version.

When updating a package other than in the core system, the -p flag, or the equivalent PKGENV logical name, must be used to indicate the system or layered product being updated. For example, "mkpkg -p noao update" would be used to update one of the packages forming the NOAO system of packages.

The CL process cache can complicate debugging and testing if one forgets that it is there. Recall that when a task is run under the CL, the executing process remains idle in the CL process cache following task termination. If a new executable is installed while the old one is still in the process cache, the flprcache command must be entered to force the CL to run the new executable. If an executable is currently running, either in the process cache or because some other user is using the program, it may not be possible to set breakpoints under the debugger.

The shared library can also complicate debugging, although for most applications-level debugging the shared library is transparent. If it is necessary to debug IRAF system libraries, contact the IRAF Hotline for assistance.

A full description of these techniques is beyond the scope of this manual, but one need not be an expert at IRAF software development techniques to perform simple updates. Most simple revisions, e.g., bug fixes or updates, can be made by merely editing or replacing the affected files and typing

cl> mkpkg update

plus maybe a flpr if the old executable is still sitting idle in the process cache.