mirror of
git://git.code.sf.net/p/cdesktopenv/code
synced 2025-02-15 04:32:24 +00:00
Remove admin/man, *nameswitch; none of this is pertinent anymore
This commit is contained in:
Jon Trulson
parent
ad01bb2067
commit
6fff16a049
15 changed files with 0 additions and 8562 deletions
File diff suppressed because it is too large
Load diff
File diff suppressed because it is too large
Load diff
|
|
@ -1,36 +0,0 @@
|
|||
.\" $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.
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
.\" $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).
|
||||
|
|
@ -1,88 +0,0 @@
|
|||
.\" $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).
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
.\" $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).
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
.\" $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).
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
.\" $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).
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
.\" $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.
|
||||
|
|
@ -1,26 +0,0 @@
|
|||
.\" $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.
|
||||
|
|
@ -1,205 +0,0 @@
|
|||
.\" $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).
|
||||
|
|
@ -1,412 +0,0 @@
|
|||
.\" $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.
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
.\" $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.
|
||||
|
|
@ -1,198 +0,0 @@
|
|||
.\" $XConsortium: binstall.5 /main/3 1995/10/30 14:07:47 rswiston $
|
||||
.TH binstall 5 "" "" CDE
|
||||
.ds )H Common Desktop Environment
|
||||
.ds ]W January 1994
|
||||
.SH NAME
|
||||
binstall \- build environment installation mechanism administration
|
||||
.SH DESCRIPTION
|
||||
This man page describes the administration of the build environment
|
||||
installation mechanism on all architectures.
|
||||
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. It uses
|
||||
.I imake
|
||||
configuration to extract 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
|
||||
.IR installpath .
|
||||
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.
|
||||
(See
|
||||
.IR binstall(1) ).
|
||||
A new pass has been added to
|
||||
.I imake
|
||||
to accomodate installing build environments ->
|
||||
.I make
|
||||
.IR binstall .
|
||||
.TP 2
|
||||
New cpp macros for \fIbinstall\fR have been added to \fIconfig/cde/cdeImake.tmpl:
|
||||
.nf
|
||||
\fIBInstallCmd\fR - location of standard make \fIinstall\fR command.
|
||||
default -> /etc/install.
|
||||
\fIBInstallTop\fR - destination location of installed build.
|
||||
default -> /tmp/binstall.
|
||||
\fIBInstallDate\fR - suffix added to installed build path (See Examples).
|
||||
default -> /**/ (nothing)
|
||||
.fi
|
||||
.TP 2
|
||||
New make macros for \fIbinstall\fR have been added to \fIconfig/cde/cdeImake.tmpl:
|
||||
.nf
|
||||
.I BINSTALL = BInstallCmd
|
||||
.I BINSTALLDATE = BInstallDate
|
||||
.I BINSTALLTOP = BInstallTop
|
||||
.I BINSTALLPATH = $(BINSTALLTOP)$(BINSTALLDATE)
|
||||
.I BINSTALL_LIBDIR = $(BINSTALLPATH)/lib
|
||||
This macro is used by vendorLib.tmpl and Project.tmpl to set new
|
||||
library paths when developer's use an installed build.
|
||||
.I BINSTALL_INCDIR = $(BINSTALLPATH)/include
|
||||
This macro resets the default include paths to the installed
|
||||
build location.
|
||||
.fi
|
||||
.TP 2
|
||||
New make rules for \fIbinstall\fR have been added to \fIconfig/cde/cde.rules :
|
||||
.nf
|
||||
NOTE: \fIdest\fR below refers to a subdirectory of \fI$BINSTALLPATH\fR.
|
||||
It is usually one of \fIlib, bin, \fRor \fIinclude.
|
||||
\fIBuildInstall(file,dest)\fR - install \fIfile\fR to \fIdest\fR.
|
||||
\fIBuildMultipleInstall(list,dest)\fR - install \fIlist\fR to \fIdest\fR.
|
||||
\fINormalLibraryBuildInstall(libname,dest)\fR - install a .a to \fIdest\fR.
|
||||
\fISharedLibraryBuildInstall(libname,rev,dest)\fR - install shlib to \fIdest\fR.
|
||||
\fIDirectoryInstall(dir,dest)\fR - install directory \fIdir\fR to \fIdest\fR.
|
||||
\fISharedLibraryBuildInstall\fR is defined in vendorLib.rules.
|
||||
The other rules are defined in \fIconfig/cde/cde.rules\fR.
|
||||
.fi
|
||||
.P
|
||||
When a build environment is installed to a path, the
|
||||
.I config
|
||||
and
|
||||
.I util
|
||||
directories are copied to the installation path. The file
|
||||
.I config/UseInstalledBuildtemplate
|
||||
is copied to the file
|
||||
.I config/treedefines
|
||||
in the install path
|
||||
.I config
|
||||
directory. This file sets the cpp macro
|
||||
.IR UseInstalledBuild .
|
||||
.I UseInstalledBuild
|
||||
will correctly point all library and header access requests to the
|
||||
install path when a developer resets the
|
||||
.I TOP
|
||||
of his Makefiles to the install path.
|
||||
.SH SETUP
|
||||
The install package path
|
||||
.I BINSTALLPATH
|
||||
is where the results of make binstall are stored. It is easiest to set
|
||||
this from the command-line or through the
|
||||
.I master_build
|
||||
script. If you want a default action for make binstall,
|
||||
each build tree may
|
||||
set
|
||||
.I BINSTALLTOP
|
||||
and optionally
|
||||
.I BINSTALLDATE
|
||||
to an appropriate path.
|
||||
These 2 macros are easiest to set through their cpp macros
|
||||
.I BInstallTop
|
||||
and
|
||||
.IR BInstallDate .
|
||||
It is recommended that
|
||||
.I BInstallTop
|
||||
be defined in the
|
||||
file
|
||||
.IR config/BuildTree.name .
|
||||
.I BINSTALLDATE
|
||||
allows you to add another
|
||||
automatically generated addition to the path set by
|
||||
.I BINSTALLTOP . In
|
||||
.IR config/hp.cf ,
|
||||
.I BInstallDate
|
||||
is defined to add
|
||||
.I /mm_dd
|
||||
to the
|
||||
.IR BINSTALLTOP .
|
||||
You may not want this to happen on your hp systems at other sites.
|
||||
Thus you should set
|
||||
.I BInstallDate to either /**/ or whatever is
|
||||
appropriate for your site in
|
||||
.I config/BuildTree.name
|
||||
for your hp builds.
|
||||
.P
|
||||
Thus, you have a choice of defining
|
||||
.I BInstallPath
|
||||
for each tree by
|
||||
defining it in
|
||||
.IR config/BuildTree.name .
|
||||
If you don't define it there, you
|
||||
will either get the default
|
||||
.I BInstallPath
|
||||
for that architecture or the
|
||||
global default (/**/). It is each vendor's responsibility to set
|
||||
.I BInstallDate
|
||||
in their .cf file if they want to add something to the
|
||||
default package install path for each of their own builds. It is
|
||||
likewise their responsibility to turn off
|
||||
.I BInstallDate
|
||||
if they do not
|
||||
want to use this mechanism for other architectures that have turned it
|
||||
on.
|
||||
.P
|
||||
However, it is still easier to set the
|
||||
.I BINSTALLPATH
|
||||
from the command line using
|
||||
.I make
|
||||
.IR BINSTALLPATH=somepath
|
||||
or from the
|
||||
.I master_build
|
||||
script(See running
|
||||
.I binstall
|
||||
below).
|
||||
.SH RUNNING BINSTALL
|
||||
Installing the build can be done in a number of ways:
|
||||
.nf
|
||||
1) running \fImake -k BINSTALLPATH=yourpath binstall\fR.
|
||||
2) running \fImake -k binstall\fR in a build tree.
|
||||
3) using the \fImaster_build\fR script with the following options:
|
||||
\fI-ba <path>\fR (run \fImake binstall\fR and supply only the \fIBINSTALLTOP\fR
|
||||
portion of the install path. \fIBINSTALLDATE\fR will be
|
||||
automatically generated and will be added to
|
||||
\fIBINSTALLTOP\fR as a subdirectory of the form \fI/mm_dd\fR.
|
||||
e.g. -ba /binstall/cde_hp700_90 on Jan 3rd. will run
|
||||
make -k BINSTALLPATH =/binstall/cde_hp700_90/01_03
|
||||
.SH FURTHER INFORMATION
|
||||
Access to binstall paths may vary for each vendor site. For information
|
||||
about the binstall paths available to developers, each site should
|
||||
create a man page of the form
|
||||
.I binstall_vendor.1
|
||||
in the
|
||||
.I admin/man/man1
|
||||
directory -> binstall_hp(1), binstall_sun(1), binstall_novell(1), binstall_ibm(1), etc..
|
||||
.SH AUTHOR
|
||||
The binstall mechanism
|
||||
was developed by Marc Ayotte,
|
||||
WTD-CV, Hewlett-Packard.
|
||||
.SH SEE ALSO
|
||||
master_build(1),
|
||||
binstall(1),
|
||||
binstall_hp(1),
|
||||
binstall_sun(1),
|
||||
binstall_novell(1),
|
||||
binstall_ibm(1).
|
||||
|
|
@ -1,66 +0,0 @@
|
|||
.\" $XConsortium: buildAdmin.5 /main/3 1995/10/30 14:07:56 rswiston $
|
||||
.TH buildAdmin 5 "" "" HP-UX
|
||||
.ds )H Hewlett-Packard Company OSSD-CV
|
||||
.ds ]W July 1993
|
||||
.SH NAME
|
||||
buildAdmin \- man page information for building administration
|
||||
.SH SYNOPSIS
|
||||
.B buildAdmin
|
||||
.SH DESCRIPTION
|
||||
This man page is an index to the man pages available for build
|
||||
administration. All of the following man pages are available by setting
|
||||
MANPATH to include /x/cdesrc/admin/man. Also see the
|
||||
.I cron_example
|
||||
file for sample build administration cron entries.
|
||||
.SH AVAILABLE MAN PAGES
|
||||
.TP 18
|
||||
.I master_build.1
|
||||
Information on the
|
||||
.I master_build
|
||||
ksh script that controls building and cloning of source and build trees.
|
||||
This is the key script used for build administration.
|
||||
.TP
|
||||
.I remote_build.1
|
||||
Information on the
|
||||
.I remote_build
|
||||
sh script that can remsh the master_build script. This gives the
|
||||
advantage of having 1 master build trigger area for cron.
|
||||
.TP
|
||||
.I cleanLinks.1
|
||||
Information on the
|
||||
.I cleanLinks
|
||||
perl script that will remove symbolic links to nowhere in a source or
|
||||
build tree. This tool is usually run daily in build trees that are
|
||||
cloned from a source tree. If files are removed or moved in the source
|
||||
tree
|
||||
.I cleanLinks
|
||||
will automatically remove the old links in the build tree.
|
||||
.TP
|
||||
.I cleanLogs.1
|
||||
Information on the
|
||||
.I cleanLogs
|
||||
ksh script that cleans older files and directories from a directory.
|
||||
This script is usually used to maintain a certain number of logs in
|
||||
the /x/logs/build directory.
|
||||
.TP
|
||||
.I ListTheTree.1
|
||||
Information on the
|
||||
.I ListTheTree
|
||||
perl script that creates 3 files at the top of a given directory structure:
|
||||
.I :TreeListing
|
||||
which contains a complete listing of all files in the tree;
|
||||
.I :TreeListing.locks
|
||||
which contains a list of all files locked and by whom;
|
||||
.I :TreeListing.changes
|
||||
which contains a list of all the files checked in since the last listing
|
||||
and who checked them in.
|
||||
This script is automatically run on /x/cdesrc daily and the listings
|
||||
come with the automatic source delivery.
|
||||
.SH SEE ALSO
|
||||
master_build(1),
|
||||
remote_build(1),
|
||||
cleanLinks(1),
|
||||
cleanLogs(1), and ListTheTree(1).
|
||||
.SH AUTHOR
|
||||
.I buildAdmin
|
||||
was developed by Marc Ayotte, OSSD-CV, Hewlett-Packard.
|
||||
Loading…
Reference in a new issue