89 lines
2.7 KiB
Groff
89 lines
2.7 KiB
Groff
.\" $XConsortium: binstall_hp.1 /main/3 1995/10/30 14:05:43 rswiston $
|
|
.TH binstall_hp 1 "" "" HP-UX
|
|
.ds )H Hewlett-Packard
|
|
.ds ]W January 1994
|
|
.SH NAME
|
|
binstall_hp \- build environment installation path availability
|
|
.SH DESCRIPTION
|
|
This man page describes the usage of the build install mechanism at
|
|
Hewlett-Packard. The focus is primarily on the default locations for the
|
|
install paths.
|
|
.TP 0
|
|
All build installation paths are available through the
|
|
.I /binstall
|
|
directory on all build systems. If you need to set up
|
|
.I /binstall
|
|
on a non-build system, examine the symbolic links and nfs mounts in
|
|
.IR /binstall .
|
|
.SH
|
|
In
|
|
.I /binstall
|
|
each build tree that has an installed build is listed as a subdirectory.
|
|
Each subdirectory under the build tree subdirectory contains an instance
|
|
of a build environment for that build tree. There are 2 types of build
|
|
tree subdirectories: automatically generated directories based on
|
|
.I mm_dd
|
|
(month_date from the
|
|
.I date
|
|
command) and any specially named subdirectories. There is also a
|
|
symbolic link
|
|
.I latest
|
|
which points to the most recent
|
|
.I mm_dd
|
|
directory. Using the
|
|
.I latest
|
|
directory will normally be equivalent to pointing
|
|
.I TOP
|
|
to a build tree. However, if the build tree is unstable,
|
|
.I latest
|
|
may be reset to the last stable build.
|
|
.SH
|
|
Each
|
|
.I mm_dd
|
|
directory has a definite lifespan that depends on the
|
|
importance of the tree and the availability of disk space. This
|
|
information is stored in
|
|
.IR /binstall/pathlife .
|
|
.SH EXAMPLES
|
|
Developer's will usually either reset
|
|
.I TOP
|
|
to
|
|
.I /binstall/treename/latest
|
|
or will set
|
|
.I TOP
|
|
to an explicit date ->
|
|
.I /binstall/treename/mm_dd.
|
|
The advantage of the former is that it allows you to stay in closer
|
|
touch to the daily bits. The advantage of the latter is that, for a
|
|
popular tree, you can choose a date when a stable build occurs and use that
|
|
date's build until it expires. However, it would be good practice to do
|
|
a test build against the latest bits before checking a critical file
|
|
in.
|
|
.TP 3
|
|
.nf
|
|
Example 1: Point your clone to the latest directory for /x/cde_hp700_90.
|
|
cd to your clone
|
|
make TOP=/x/cde_hp700_90/latest Makefile
|
|
make Makefiles (optional)
|
|
.fi
|
|
.TP
|
|
.nf
|
|
Example 2: Point your clone to the Jan. 3rd build for /x/cde_hp700_90.
|
|
cd to your clone
|
|
make TOP=/x/cde_hp700_90/01_03 Makefile
|
|
make Makefiles (optional)
|
|
.SH PACKAGE INFORMATION
|
|
Check the
|
|
.I /binstall
|
|
directory on any build system to scan the available paths.
|
|
The duration of mm_dd paths is normally 7 days. For debuggable trees, the
|
|
default duration will be 2-4 days. The duration for each set of paths
|
|
can be read from the file
|
|
.IR /binstall/pathlife.
|
|
The binstall mechanism
|
|
was developed by Marc Ayotte,
|
|
WTD-CV, Hewlett-Packard.
|
|
.SH SEE ALSO
|
|
binstall(1),
|
|
binstall(5).
|