Package Hierarchy Details

The package directory hierarchy is rooted at $PACKAGEROOT. All source and binaries reside under this tree. A two level viewpath is used to separate source and binaries. The top view is architecture specific, the bottom view is shared source. All building is done in the architecture specific view; no source view files are intentionally changed. This means that many different binary architectures can be made from a single copy of the source.

Each package contains one or more components. Component source for the FOO command is in $PACKAGEROOT/src/cmd/FOO, and source for the BAR library is in $PACKAGEROOT/src/lib/libBAR. This naming is for convenience only; the underlying makefiles handle inter-component build order. The INIT component, which contains generic package support files, is always made first, then the components named INIT*, then the order determined by the closure of component makefile dependencies.

$PACKAGEROOT/lib/package contains package specific files. The package naming convention is GROUP[-PART]; e.g., ast-base, gnu-fileutils. The *.pkg files are ast nmake(1) makefiles that contain the package name, package components, references to other packages, and a short package description. *.pkg files are used by package write to generate new source and binary packages.

$PACKAGEROOT/lib/package/GROUP.lic files contain license information that is used by the ast proto(1) and nmake(1) commands to generate source and binary license strings. GROUP is determined by the first :PACKAGE: operator name listed in the component nmake makefile. GROUP.lic files are part of the licensing documentation. Each component may have its own LICENSE file that overrides the GROUP.lic file. The full text of the licenses are in the $PACKAGEROOT/lib/package/LICENSES and $INSTALLROOT/lib/package/LICENSES directories.

A few files are generated in $PACKAGEROOT/lib/package/gen and $INSTALLROOT/lib/package/gen. PACKAGE.ver contains one line consisting of

	PACKAGE VERSION RELEASE 1
for the most recent instance of PACKAGE read into $PACKAGEROOT, where PACKAGE is the package name, VERSION is the YYYY-MM-DD base version, and RELEASE is VERSION for the base release or YYYY-MM-DD for delta releases. PACKAGE.req contains *.ver entries for the packages required by PACKAGE, except that the fourth field is 0 instead of 1. All packages except INIT and ratz require the INIT package. A simple sort of PACKAGE.pkg and *.ver determines if the required package have been read in. Finally, PACKAGE.README contains the README text for PACKAGE and all its components. Included are all changes added to the component RELEASE, CHANGES or ChangeLog files dated since the two most recent base releases. Component RELEASE files contain tag lines of the form [CC]YY-MM-DD [ TEXT ] (or date(1) format dates) followed by README text, in reverse chronological order (newer entries at the top of the file.) package release generates this information, and package contents ... lists the descriptions and components.

$HOSTYPE names the current binary architecture and is determined by the output of package (no arguments.) The $HOSTTYPE naming scheme is used to separate incompatible executable and object formats. All architecture specific binaries are placed under $INSTALLROOT ($PACKAGEROOT/arch/$HOSTTYPE.) There are a few places that match against $HOSTTYPE when making binaries; these are limited to makefile compiler workarounds, e.g., if $HOSTTYPE matches 'hp.*' then turn off the optimizer for these objects. All other architecture dependent logic is handled either by $INSTALLROOT/bin/iffe or by component specific configure scripts. Explicit $HOSTYPE values matching *,*cc*[,-*,...] optionally set the default CC and CCFLAGS. This is handy for build farms that support different compilers on the same architecture.

Each component contains an ast nmake(1) makefile (either Nmakefile or Makefile) and a MAM (make abstract machine) file (Mamfile.) A Mamfile contains a portable makefile description that is used by $INSTALLROOT/bin/mamake to simulate nmake. Currently there is no support for old-make/gnu-make makefiles; if the binaries are just being built then mamake will suffice; if source or makefile modifications are anticipated then nmake (from the ast-open or ast-base package) should be used. Mamfiles are automatically generated by package write.

Most component C source is prototyped. If $CC (default value cc) is not a prototyping C compiler then package make runs proto(1) on portions of the $PACKAGEROOT/src tree and places the converted output files in the $PACKAGEROOT/proto/src tree. Converted files are then viewpathed over the original source. The ast proto(1) command converts an ANSI C subset to code that is compatible with K&R, ANSI, and C++ dialects.

All scripts and commands under $PACKAGEROOT use $PATH relative pathnames; there are no imbedded absolute pathnames. This means that binaries generated under $PACKAGEROOT may be copied to a different root; users need only change their $PATH variable to reference the new instalation root bin directory. package install installs binary packages in a new $INSTALLROOT.