Initial import of the CDE 2.1.30 sources from the Open Group.

cde/admin/man/man1/ListTheTree.1

@@ -0,0 +1,36 @@
+.\" $XConsortium: ListTheTree.1 /main/3 1995/10/30 14:04:20 rswiston $
+.TH ListTheTree 1 "" "" HP-UX
+.ds )H Hewlett-Packard Company OSSD-CV
+.ds ]W July 1993
+.SH NAME
+ListTheTree \- OSSD-CV tree and lock listing script
+.SH SYNOPSIS
+.B ListTheTree
+.I <directory>
+DIRECTORY MUST BEGIN with "/"
+.SH DESCRIPTION
+.I ListTheTree
+is a perl script that creates three files in 
+.IR directory :
+.IR :TreeListing ,
+.IR :TreeListing.locks ,
+and
+.IR :TreeListing.changes .
+.I :TreeListing 
+contains a complete recursive listing of all of the files in 
+.IR directory .
+.I :TreeListing.locks
+contains a complete recursive listing of all of the files in
+.IR directory
+that are locked in RCS, and the name of the locker.
+.I :TreeListing.changes
+contains a complete listing of all of the files that have been 
+checked in since the last listing and who checked them in.
+.SH SEE ALSO
+master_build(1),
+buildAdmin(5).
+.SH AUTHOR
+.I ListTheTree
+was originally developed by Jim Andreas, OSSD-CV, Hewlett Packard.
+It was modified extensively and converted to a perl script by
+Marc Ayotte, OSSD-CV, Hewlett Packard.

cde/admin/man/man1/binstall.1

@@ -0,0 +1,70 @@
+.\" $XConsortium: binstall.1 /main/3 1995/10/30 14:05:34 rswiston $
+.TH binstall 1 "" "" CDE
+.ds )H Common Desktop Environment
+.ds ]W January 1994
+.SH NAME
+binstall \- build tree build environment installation mechanism
+.SH DESCRIPTION
+This man page is an index into the build installation mechanism set up
+by 
+.I imake
+for the CDE build environment.  
+This mechanism was set up to allow developers to use alternative build
+environments (usually from some previous day's build) when build trees
+are unstable.
+The mechanism extracts libraries,
+headers, make configuration, and binaries from a build tree and installs
+them in a designated location. If
+.I installpath
+is the installation location, 
+.I make binstall
+will create the following directories under
+.IR installpath :
+.I include
+(and subdirectories), 
+.IR lib ,
+.IR bin ,
+.IR config ,
+and
+.IR util .
+The mechanism can also create any other needed directories under
+.IR installpath .
+These directories can then be accessed by a developer by pointing the
+.I TOP 
+of his Makefiles to
+.I installpath 
+(See Examples below).
+Most components (including imake-oriented components not in any build
+tree) can then leverage the libraries, headers, etc. in the binstall
+path and build correctly.
+.SH EXAMPLES
+A developer can use the headers, libraries, etc. located under the
+.I installpath 
+by doing the following:
+.TP 3
+1) Create or copy the directory structure you are developing. It is
+assumed that this structure is using imake. If there is no Makefile at
+the top of directory  structure, copy one from any build tree for your
+architecture.
+.TP
+2) cd to the top of your directory structure. 
+.TP
+3) 
+.I make TOP=installpath Makefile; [make Makefiles];make
+.SH FURTHER INFORMATION
+Access to binstall paths may vary for each vendor site. For information
+about the binstall paths available to developers, see each site's man
+page of the form binstall_vendor(1)-> binstall_hp(1), binstall_sun(1),
+binstall_novell(1), binstall_ibm(1), etc..
+For information about the administration of binstall see 
+.IR binstall (5).
+.SH AUTHOR
+The binstall mechanism
+was developed by Marc Ayotte,
+WTD-CV, Hewlett-Packard.
+.SH SEE ALSO
+binstall_hp(1),
+binstall_sun(1),
+binstall_novell(1),
+binstall_ibm(1),
+binstall(5).

cde/admin/man/man1/binstall_hp.1

@@ -0,0 +1,88 @@
+.\" $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).

cde/admin/man/man1/binstall_ibm.1

@@ -0,0 +1,16 @@
+.\" $XConsortium: binstall_ibm.1 /main/3 1995/10/30 14:06:01 rswiston $
+.TH binstall_ibm 1 "" "" AIX
+.ds )H IBM
+.ds ]W January 1994
+.SH NAME
+binstall_ibm \- build environment installation path availability
+.SH DESCRIPTION
+This man page describes the usage of the build install mechanism at
+IBM. The focus is primarily on the default locations for the
+install paths.
+.SH EXAMPLES
+.SH PACKAGE INFORMATION
+Currently no information is yet available for this package.
+.SH SEE ALSO
+binstall(1),
+binstall(5).

cde/admin/man/man1/binstall_novell.1

@@ -0,0 +1,16 @@
+.\" $XConsortium: binstall_novell.1 /main/3 1995/10/30 14:06:09 rswiston $
+.TH binstall_novell 1 "" "" UNIX_SV
+.ds )H Novell
+.ds ]W January 1994
+.SH NAME
+binstall_novell \- build environment installation path availability
+.SH DESCRIPTION
+This man page describes the usage of the build install mechanism at
+Novell. The focus is primarily on the default locations for the
+install paths.
+.SH EXAMPLES
+.SH PACKAGE INFORMATION
+Currently no information is yet available for this package.
+.SH SEE ALSO
+binstall(1),
+binstall(5).

cde/admin/man/man1/binstall_sun.1

@@ -0,0 +1,16 @@
+.\" $XConsortium: binstall_sun.1 /main/3 1995/10/30 14:06:18 rswiston $
+.TH binstall_hp 1 "" "" SunOS
+.ds )H Sun Microsystems
+.ds ]W January 1994
+.SH NAME
+binstall_sun \- build environment installation path availability
+.SH DESCRIPTION
+This man page describes the usage of the build install mechanism at
+Sun Microsystems. The focus is primarily on the default locations for the
+install paths.
+.SH EXAMPLES
+.SH PACKAGE INFORMATION
+Currently no information is yet available for this package.
+.SH SEE ALSO
+binstall(1),
+binstall(5).

cde/admin/man/man1/cleanLinks.1

@@ -0,0 +1,23 @@
+.\" $XConsortium: cleanLinks.1 /main/3 1995/10/30 14:06:27 rswiston $
+.TH cleanLinks 1 "" "" HP-UX
+.ds )H Hewlett-Packard Company OSSD-CV
+.ds ]W July 1993
+.SH NAME
+cleanLinks \- OSSD-CV symbolic link to nowhere cleanup script
+.SH SYNOPSIS
+.B cleanLinks
+.I <directory>
+.SH DESCRIPTION
+.I cleanLinks
+is a perl script that cleans the directory structure(given by
+.IR directory )
+of files and directories that 
+are symbolic links to nowhere. It does not remove any path name that
+ends in RCS. It sends information on what files are removed to stdout.
+Error information is sent to stderr.
+.SH SEE ALSO
+master_build(1),
+buildAdmin(5).
+.SH AUTHOR
+.I cleanLinks
+was developed by Marc Ayotte OSSD-CV, Hewlett-Packard.

cde/admin/man/man1/cleanLogs.1

@@ -0,0 +1,26 @@
+.\" $XConsortium: cleanLogs.1 /main/3 1995/10/30 14:06:35 rswiston $
+.TH cleanLogs 1 "" "" HP-UX
+.ds )H Hewlett-Packard Company OSSD-CV
+.ds ]W June 1993
+.SH NAME
+cleanLogs \- OSSD-CV script to remove excessive build logs
+.SH SYNOPSIS
+.B cleanLogs
+.RI [ \|options\| ]
+.SH DESCRIPTION
+.I cleanLogs
+removes directories and files from a system. If no options are given, it
+will leave the 14 newest directories in the /x/logs/build directory.
+This script is generally run as part of the master cron for all builds.
+See the
+.I cron_example
+file.
+If one option is given, it is assumed to be the directory path
+that should be cleaned.  If two options are given, the second option is
+the number of files or directories that should remain after cleaning.
+.SH SEE ALSO
+master_build(1),
+buildAdmin(5).
+.SH AUTHOR
+.I cleanLogs
+was developed by Marc Ayotte OSSD-CV, Hewlett-Packard.

cde/admin/man/man1/fnrclone.1

@@ -0,0 +1,205 @@
+.\" $XConsortium: fnrclone.1 /main/3 1995/10/30 14:06:44 rswiston $
+.TH fnrclone 1 "" "" HP-UX
+.ds )H Hewlett-Packard Company OSSD-CV
+.ds ]W July 1993
+.SH NAME
+fnrclone \- OSSD-CV symbolic link creation front end to findnewrcs
+.SH SYNOPSIS
+.B fnrclone
+.RI [ \|options\| ]
+.I <source>
+.I <destination>
+.SH DESCRIPTION
+.I fnrclone
+is a ksh front-end to the
+.I findnewrcs
+program
+that duplicates the directory structure of 
+.I source
+into
+.IR destination .
+It is usually used with no options.
+.TP 6
+The default behavior is findnewrcs -XLlmiA which causes the following:
+All of the directories in 
+.IR source ,
+except any
+.I RCS
+or
+.I SCCS
+directories, are recreated as real directories in 
+.IR destination .
+All of the files in 
+.I source
+are recreated as symbolic links to
+.I source
+in
+.IR destination .
+Any 
+.I RCS
+directories in 
+.I source 
+are recreated as symbolic links to 
+.I source
+in 
+.IR destination .
+Any 
+.I SCCS
+directories in
+.I source
+are ignored unless the
+.IR -C
+option is specified.
+If 
+.I source
+contains symbolic links, these links are resolved to their final
+link point in
+.I destination
+unless the 
+.I -S
+option is specified.
+.I Fnrclone
+will convert read-only files in 
+.I destination
+to symbolic links if they exist in both
+.I source
+and
+.I destination
+and the file in 
+.I source
+is newer than the file in
+.IR destination .
+If the file in
+.I destination
+is writable (as in files locked by a user),
+the file will NOT be converted to a symbolic link to 
+.IR source .  
+.PP
+If the RCS directory is accessible, any new files in the RCS directory
+will be checked out as real files in
+.IR destination .
+If the
+.I -c 
+option is given and the RCS directory is accessible, files that are
+newer in the RCS directory will be checked out as real files in
+.IR destination .
+.PP
+The 
+.I -n 
+option causes regular files to be copied to
+.I destination
+instead of linked.
+The
+.I -s 
+option causes old-style behavior where the actions are placed in a
+script file and the log information in a log file. The script is then
+executed.
+The 
+.I -d 
+option causes 
+.I findnewrcs
+to descend symbolically linked directories instead of just
+recreating the link. This is very old behaviour, and probably used
+infrequently.
+The -f option allows you to specify a log file (generated by stderr)
+containing the actions generated by 
+.I findnewrcs 
+and
+.IR fnrclone .
+.SS Options
+.TP 8
+.I -c
+This option forces the checkout of a file from the RCS directory if
+the file is newer in the RCS directory than the file in 
+.IR destination .
+It will also check out any brand new files from the RCS directory into
+.IR destination .
+This option only works if the RCS directory or ,v files can be accessed
+by the user. In the remote source exchange, this is not true, and this
+option has no effect so you may need to explicitly check out the
+current revision of any file.  See
+.IR Co(1) .
+.TP
+.I -s
+This option triggers the following:
+.br
+\- The directory $HOME/fnrclone will be created for the user if it does not
+exist.
+.br
+\- The stdout of 
+.I findnewrcs 
+will be placed into
+$HOME/fnrclone/script.HHMMSS. This script contains shell versions of the
+commands that 
+.I findnewrcs 
+would execute. The script is then executed.
+.br
+\- The stderr of 
+.I findnewrcs
+will be placed into
+$HOME/fnrclone/log.HHMMSS. This contains a log of files that have
+changed and any errors.
+.IP
+If the
+.I -l 
+option has also been specified, the log file will be duplicated
+in
+.IR logfile .
+.TP
+.I -S
+This option tells fnrclone to not resolve symbolic links when cloning.
+The usual behavior is to resolve the symbolic links in 
+.I source
+to a real file.  This option is handy when cloning multiple build
+directories from a single working source when that source itself has
+been cloned from a master source. The links in 
+.I source 
+point to the
+master source. The links in the build directories will point to 
+.I source
+but not resolve through to the master source.
+.TP
+.I -C
+Frnclone's normal behavior is to not clone SCCS directories. This option
+causes SCCS directories to be cloned similar to other directories.
+.TP
+.I -n
+This option copies files from 
+.I source
+to 
+.I destination
+rather than link them. This behavior can create some interesting side
+effects. For instance, files that are symlinked from one path in
+.I source
+to another path in 
+.I source
+become unlinked in
+.I destination
+with identical copies placed in the two path locations in 
+.IR destination .
+.TP
+.I -f <logdir>
+This option takes the stderr of
+.I findnewrcs
+and places it into logfile. This file will contain useful information
+on what files have changed and also errors from findnewrcs.
+.TP
+.I -d
+This option causes
+.I findnewrcs
+to descend symbolically linked directories when traversing a tree.
+This is an old option that may be obsolete.
+.TP
+.I -u
+This option prints a usage message.
+.SH EXAMPLES
+Clone the directory structure in /x/cdesrc/doc/unity1 to mydir/doclone.
+.IP
+fnrclone /x/cdesrc/doc/unity1 mydir/doclone
+.SH AUTHOR
+.I fnrclone
+was developed by Marc Ayotte, OSSD-CV, Hewlett-Packard.
+.I findnewrcs
+was developed by Dave Serisky, OSSD-CV, Hewlett-Packard.
+.SH SEE ALSO
+findnewrcs(1).

cde/admin/man/man1/master_build.1

@@ -0,0 +1,412 @@
+.\" $XConsortium: master_build.1 /main/3 1995/10/30 14:06:53 rswiston $
+.TH master_build 1 "" "" HP-UX
+.ds )H Hewlett-Packard Company OSSD-CV
+.ds ]W June 1993
+.SH NAME
+master_build \- OSSD-CV master build and source synchronization script.
+.SH SYNOPSIS
+.B master_build
+.RI [ \|options\| ]
+.SH DESCRIPTION
+.I master_build
+is a ksh script that controls building of build trees from a central
+location. It can also be used for source synchronization.
+If the
+.I -clone
+option is used, the
+.I -src
+option
+determines the source directory for source code synchronization. If the
+.I -build 
+option is used, it is synchronized with the source directory associated
+with 
+.IR -src .
+If the 
+.I -c
+option is used, 
+.I -build 
+is used to determine the build directory. The 
+.I -n 
+option restricts the scope of any builds to just 
+.IR make .
+The 
+.I -noIgnore
+option will cause 
+.I make
+to exit upon encountering an error.  The default is to just stop
+building the current target upon error but continue building
+all of the rest of the targets (
+.I make
+.I -k 
+).
+The 
+.I -l
+option causes a 
+.I make
+of lint libraries.
+The 
+.I -w 
+option removes all targets before building.
+There are certain tools that are run inside
+.I master_build
+which are located in a standard location. The
+.I -t
+option allows a user to specify an alternate location.
+The
+.I -m
+option allows certain summary mail information to be sent to interested
+parties.
+.P
+Remote building via remsh can be triggered by the
+.I remote_build
+script. 
+See
+.IR remote_build(1) .
+.P
+The 
+.I cron_example
+file gives example cron entries for build administration.
+.SH LOGGING INFORMATION
+If the 
+.I -build 
+option is present, log files generated by
+.I master_build
+are placed in the /x/logs/build/mmdd/buildtree directory.
+If only the 
+.I -src 
+option was specified, log files are placed 
+in the /x/logs/build/mmdd/sourcetree directory.
+If the 
+.I -l 
+option is specified it replaces the /x/logs/build portion of the
+above path. The following files may be present in a log directory:
+.TP 18
+.I allmake.HHMMSS
+This file contains output from make Makefile, make Makefiles, make
+clean, make includes and make depend.
+.TP
+.I make.HHMMSS
+This file contains output from make only.
+.TP
+.I lint.HHMMSS
+This file contains output from the 
+.I -l
+option.
+.TP
+.I cloneerr.HHMMSS
+This file contains error messages generated by the 
+.I -clone 
+option.
+.TP
+.I cloneerr.HHMMSS
+This file contains a listing of the files that have been
+resynchronized by the 
+.I -clone
+option.
+.TP
+.I cleanlinks.HHMMSS
+This file contains information on symbolic links to nowhere removed
+by the
+.I -cl
+option.
+.TP
+.I summary.HHMMSS
+This file contains output generated by the
+.I -m 
+option.
+.P
+Log directories are trimmed to a certain number based on age by the
+.I cleanLogs
+script.
+See
+.IR cleanLog(1) .
+.SS Options
+.I master_build
+recognizes the following options:
+.RS
+.TP 15
+.I -src <source>
+The 
+.I source
+directory is the directory that is used as the source for any
+cloning operations with the 
+.I -clone 
+option listed below.
+.TP
+.I -build <build>
+The 
+.I build 
+directory is the build tree that will either be built with either the
+.I -c
+or
+.I -l
+option and/or cloned.
+The 
+.I build 
+directory is only necessary if you are either doing
+builds or cloning a source tree into a build tree.
+The
+.I -clone 
+option will use  
+.I source 
+as the source directory and 
+.I build 
+as the destination directory for 
+.IR fnrclone .
+.TP
+.I -clone <n|s|c|sync>
+The 
+.I -clone 
+option will use
+.I source 
+as the source directory and 
+.I build 
+as the destination directory for 
+.IR fnrclone .
+If the
+.I -build
+option is missing,
+.I source 
+will be both the source and destination directory for
+.IR fnrclone .
+The
+.I n
+parameter causes real files to be checked out into the destination
+directory with symbolically linked RCS directories. This is the same
+behavior as
+.I fnrclone
+.IR -n .
+The 
+.I s
+parameter symbolically links files from the source to the destination
+and creates symbolically linked RCS directories. However, it will not
+check out new revisions of any source files from RCS but will merely
+synchronize source and destination. This is the same as the default
+behavior for
+.I fnrclone
+and this is the recommended option for use when cloning build trees
+from a source tree in the
+.I master_build
+script.
+The
+.I c
+and
+.I sync
+parameters behave like the
+.I s
+parameter but will check new files out of RCS. This is generally only
+done when cloning a source tree to itself (no
+.I -build
+option) and is meaningless when the RCS vaults are not visible as in the
+CDE source exchange. This is the same behavior as 
+.I fnrclone
+.I -c 
+and is the recommended operation to use when syncing a source tree to
+itself.
+See 
+.I fnrclone(1)
+for more information.
+The 
+.I -sync
+option is being obsoleted and may be removed in the future.
+Moving or removing files in 
+.I -src
+can result in symbolic links to nowhere after cloning in 
+.IR -build .
+The 
+.I cleanLinks 
+script can be run to remove these links. See the 
+.I -cl
+option below and
+.IR cleanLinks(1) .
+.TP
+.I -cl
+Clean symbolic links to nowhere in either
+.I -src
+or
+.IR -build .
+As above with the 
+.I -clone
+option, if no
+.I -build
+option is given,
+.I -src 
+is used as the tree to be cleaned.
+Symbolic links to nowhere will occur in build trees when files are moved
+or removed from 
+.I -src
+and 
+.I -build 
+is cloned from
+.IR -src .
+The 
+.I cleanLinks 
+script will remove all symbolic links to nowhere whose
+path does not end in RCS. See
+.IR cleanLinks(1) .
+.TP
+.I -c
+Do a complete build of the 
+.I build 
+directory.
+This option triggers
+.I make 
+.I -k
+Makefile,
+.I make 
+.I -k
+Makefiles,
+.I make 
+.I -k
+includes,
+.I make 
+.I -k
+depend,
+and
+.I make 
+.IR -k .
+if the 
+.I -noIgnore 
+option is set, the 
+.I -k
+option to 
+.I make 
+is ignored.
+.TP
+.I -n
+When used in conjunction with the 
+.I -c
+option, only do a 
+.IR make .
+Do not do 
+.I make
+Makefile,
+.I make
+Makefiles, 
+.I make
+includes, etc.
+.TP
+.I -w
+When used in conjunction with the
+.I -c
+option
+do a 
+.I make
+clean. That is remove any clean targets such as .o's, .a's, executables,
+etc.
+.TP
+.I -l
+Do a 
+.I make
+.I [-k] 
+.IR lintlibs .
+This option creates lint libraries. The log file 
+generated by this option is lint.HHMMSS.
+.TP
+.I -noIgnore
+This option removes the default
+.I -k 
+option from all makes. This causes each particular make(
+.I make
+.IR Makefile ,
+.I make 
+.IR Makefiles ,
+etc.)
+to stop on encountering the first error.
+.TP
+.I -log <logdir>
+Normally log files are placed in either the
+.I /x/logs/build/mmdd/source
+directory or the 
+.I /x/logs/build/mmdd/build
+directory(see logging information above).  This option allows you to
+to replace the 
+.I /x/logs/build
+directory as the logging destination with 
+.IR logdir .
+.TP
+.I -ba <path>
+Run 
+.I make binstall
+and create an automatic install path. This path is of the form
+.I path/mm_dd
+where
+.I path
+is the supplied path and
+.I mm_dd
+is the date the build started (month_day).
+When using this option, you must also use the
+.I -build
+option and specify a build tree to run 
+.I make binstall
+upon.
+The
+.I -cb
+option below allows you to specify how many 
+.I mm_dd 
+directories you want to maintain in
+.IR path.
+.TP
+.I -cb <number of directories>
+This option trims the number of binstall directories created by the
+.IR -ba
+option. It leaves the number of directories specified. It must be used
+with the 
+.IR -ba 
+option. It only trims directories of the type mm_dd(e.g 02_05).
+.TP
+.I -t <tooldir>
+Certain operations such as cloning, assume that tools such as fnrclone
+are located in the /x/cdesrc/admin/BuildTools directory.  
+This option allows you to specify an alternate location for tools that 
+.I master_build
+needs. Currently 
+.I master_build 
+accesses the following tools:
+.IR fnrclone ,
+and
+.IR sys_calls .
+.I fnrclone 
+also currently has internal dependencies to /usr/local/bin.
+.I sys_calls 
+gets correct versions of the 
+.I date
+command for each architecture.
+.TP
+.I -m <mail_list>
+Sends information concerning bad options to
+.IR master_build , 
+and  the start and stop time of builds to 
+.IR mail_list .
+.TP
+.I -ld <ldoptions>
+This option passes 
+.I ldoptions
+to the 
+.I LDOPTS
+environment variable before 
+.I make
+is started.  This option is little used and may be obsolete.
+.TP
+.I -model <model> (Apollo only)
+This option passes apollo machine types to 
+.IR master_build .
+It is generally not used.
+.TP
+.I -be <chrootdir> (HP only)
+This option is used for HP chroot build environment builds. It will not
+work for any other architecture.
+.SH SEE ALSO
+remote_build(1),
+cleanLinks(1),
+cleanLogs(1),
+ListTheTree(1),
+fnrclone(1),
+buildAdmin(5).
+.SH AUTHOR
+.I master_build
+was originally developed by Nathan Meyers, OSSD-CV, Hewlett-Packard. 
+It was greatly expanded, modified,
+and renamed twice by Marc Ayotte, OSSD-CV, Hewlett-Packard.
+Other key modifiers have been Jim Andreas, Ron Voll, and Fred Handloser
+of OSSD-CV, Hewlett-Packard.

cde/admin/man/man1/remote_build.1

@@ -0,0 +1,31 @@
+.\" $XConsortium: remote_build.1 /main/3 1995/10/30 14:07:04 rswiston $
+.TH remote_build 1 "" "" HP-UX
+.ds )H Hewlett-Packard Company OSSD-CV
+.ds ]W July 1993
+.SH NAME
+remote_build \- OSSD-CV remote startup script for the
+.I master_build
+script.
+.SH SYNOPSIS
+.B remote_build
+.I <remote host>
+.RI [ \|options\| ]
+.SH DESCRIPTION
+.I remote_build
+is a shell script that remsh's to 
+.I remote host
+and executes the
+.I master_build 
+script with
+.IR options .
+All normal 
+.I remsh
+permissions, etc. must be set up for the script to execute
+successfully. This script exists so that a builder can use one master
+cron file to execute all of his builds.
+.SH SEE ALSO
+master_build(1),
+buildAdmin(5).
+.SH AUTHOR
+.I remote_build
+was developed by Marc Ayotte OSSD-CV, Hewlett-Packard.