Spelling fixes from Adam Di Carlo adam@onshore-devel.com
git-svn-id: svn://10.0.0.236/trunk@111239 18797224-902f-48f8-a5cc-f745e15eee43
This commit is contained in:
@@ -32,8 +32,8 @@
|
||||
# complete rewrite by Ken Estes, Mail.com (kestes@staff.mail.com).
|
||||
# Contributor(s):
|
||||
|
||||
# $Revision: 1.13 $
|
||||
# $Date: 2001-11-14 21:21:02 $
|
||||
# $Revision: 1.14 $
|
||||
# $Date: 2002-01-02 18:09:59 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Name: not supported by cvs2svn $
|
||||
|
||||
@@ -52,7 +52,7 @@ use IPC::Open3;
|
||||
|
||||
# The build script does not use the normal tinderbox libraries, it
|
||||
# does need its own local configuration file though. We find that
|
||||
# file via the normal libarary search path.
|
||||
# file via the normal library search path.
|
||||
|
||||
use lib '#tinder_libdir#';
|
||||
|
||||
@@ -67,8 +67,8 @@ Global Options:
|
||||
(These options apply to all builds)
|
||||
|
||||
--daemonize Run program in the background.
|
||||
--once Do not loop repeadly.
|
||||
--noreport Do not mail status reorts to the tinderbox server.
|
||||
--once Do not loop repeatedly.
|
||||
--noreport Do not mail status reports to the tinderbox server.
|
||||
--test Print the build commands, do not run the build
|
||||
commands or mail logs.
|
||||
--build BUILDTYPE The name of the build type to run. You may specify
|
||||
@@ -100,7 +100,7 @@ Build Options:
|
||||
your configuration. They are listed here as a suggestion only.)
|
||||
|
||||
--depend Build depend (must have this option or clobber).
|
||||
--clobber Build clobber (the oposite of depend).
|
||||
--clobber Build clobber (the opposite of depend).
|
||||
--tag TREETAG Checkout CVS sources by tag (-r TREETAG).
|
||||
|
||||
Summary:
|
||||
@@ -137,12 +137,12 @@ Makefile).
|
||||
Different sequences of build instructions have different 'build
|
||||
names'. How you name your builds depends on the type of build testing
|
||||
you are performing. You may have architecture build names:
|
||||
(Macintosh, Solaris, NT,) or project/subsystem specific build names
|
||||
(Macintosh, Solaris, NT) or project/subsystem specific build names
|
||||
(Sendmail, SeaMonkey, Apache) or functionality specific build names
|
||||
(Construct, Lint_Test, Functionality_Test, Coverage_Test,
|
||||
Performance_Test) or some combination of the above.
|
||||
|
||||
What make this a bit compilcated is that several different parameters
|
||||
What make this a bit complicated is that several different parameters
|
||||
(clobber/dep, the branch name to checkout from version control,
|
||||
optimize/debug compilation flags, other application specific compile
|
||||
time flags) will likely be tested by the same build script so our
|
||||
@@ -153,7 +153,7 @@ defines the builds.
|
||||
|
||||
It is assumed that each line in the build script can be safely
|
||||
executed in its own shell and that if any command fails it will exit
|
||||
with a non zero exit code. This is similar to the behahvior of
|
||||
with a non zero exit code. This is similar to the behavior of
|
||||
make. Failed builds are started again from the beginning during the
|
||||
next build cycle.
|
||||
|
||||
@@ -163,11 +163,11 @@ but the list of commands that would be run when the '--test' argument
|
||||
is removed is sent to STDOUT for examination.
|
||||
|
||||
Before the logs can be mailed to tinderbox there must be information
|
||||
discribing how to display this information. Tinderbox maintains two
|
||||
describing how to display this information. Tinderbox maintains two
|
||||
variables for this purpose. The tinderbox tree name picks which web
|
||||
page the information will be displayed on. The tinderbox build name
|
||||
is the name used for the column that the data will be displayed in.
|
||||
Typically there is one deamon running continually for each column of
|
||||
Typically there is one daemon running continually for each column of
|
||||
each page. It may be clearer to have different build names display on
|
||||
the tinderbox columns then are used by this build script.
|
||||
|
||||
@@ -196,7 +196,7 @@ sub set_static_vars {
|
||||
|
||||
# This functions sets all the static variables which are often
|
||||
# configuration parameters. Since it only sets variables to static
|
||||
# quantites it can not fail at run time. Some of these variables are
|
||||
# quantities it can not fail at run time. Some of these variables are
|
||||
# adjusted by parse_args() but aside from that none of these
|
||||
# variables are ever written to. All global variables are defined here
|
||||
# so we have a list of them and a comment of what they are for.
|
||||
@@ -222,15 +222,15 @@ sub set_static_vars {
|
||||
$BUILDCF = "buildcf";
|
||||
|
||||
# minimum time between the start of consecutive builds. Tinderbox
|
||||
# requires this to be grater then 5 mintues.
|
||||
# requires this to be grater then 5 minutes.
|
||||
|
||||
$MINIMUM_BUILD_SECONDS = 8*60;
|
||||
|
||||
# The maximum amount of time between tinderbox reports. These can
|
||||
# be as frequent as you like but more frequent will chew up your
|
||||
# disk space, network bandwith and processor time. People do not
|
||||
# disk space, network bandwidth and processor time. People do not
|
||||
# need to know exactly where tinderbox is in a build, it only makes
|
||||
# sense to make this about the same size as the tinderbox referesh
|
||||
# sense to make this about the same size as the tinderbox refresh
|
||||
# rate.
|
||||
|
||||
$REPORT_TINDERBOX_EVERY_SECONDS = 5*60;
|
||||
@@ -250,7 +250,7 @@ sub set_static_vars {
|
||||
# '');
|
||||
|
||||
# taint perl requires we clean up these bad environmental variables
|
||||
# and it dos not hurt to do it here.
|
||||
# and it does not hurt to do it here.
|
||||
|
||||
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV', 'LD_PRELOAD'};
|
||||
|
||||
@@ -275,7 +275,7 @@ sub get_env {
|
||||
# handling, should things fail.
|
||||
|
||||
# This function should run as early as possible (directly after
|
||||
# set_static_vars) so that the error environment is setup incase of
|
||||
# set_static_vars) so that the error environment is setup in case of
|
||||
# problems.
|
||||
|
||||
umask 0022;
|
||||
@@ -436,7 +436,7 @@ sub set_server_args {
|
||||
die("Must define an error parser.\n");
|
||||
|
||||
($ADMINISTRATOR) ||
|
||||
die("Must define a build adminstrator.\n");
|
||||
die("Must define a build administrator.\n");
|
||||
|
||||
($MAIL_FROM) ||
|
||||
die("Must define a mailing address to send builds to.\n");
|
||||
@@ -449,7 +449,7 @@ sub set_server_args {
|
||||
}
|
||||
|
||||
|
||||
# Ensure that user defined build structure has all the manditory
|
||||
# Ensure that user defined build structure has all the mandatory
|
||||
# parts.
|
||||
|
||||
sub check_builds {
|
||||
@@ -596,7 +596,7 @@ sub nonblock {
|
||||
|
||||
sub system3 {
|
||||
|
||||
# Lanuch a new child and wait for it to die. This is like a call to
|
||||
# Launch a new child and wait for it to die. This is like a call to
|
||||
# system but we get the stdout and stderr in addition to $?.
|
||||
|
||||
# call the function like this
|
||||
@@ -709,7 +709,7 @@ sub system3 {
|
||||
} # while pid
|
||||
|
||||
($reaped_pid != $child_pid) &&
|
||||
warn("No Child pid recived. ".
|
||||
warn("No Child pid received. ".
|
||||
"reaped_pid: $reaped_pid, ".
|
||||
"child_pid: $child_pid, ".
|
||||
"wait_status: $wait_status, ".
|
||||
@@ -868,7 +868,7 @@ sub slow_build_speed {
|
||||
foreach $tree_name (split(/:/, $TREE_NAME)) {
|
||||
|
||||
# We need to rerun the user code each iteration so that
|
||||
# they can set file names with embeded dates. This
|
||||
# they can set file names with embedded dates. This
|
||||
# allows each build to be saved in a separate tar file
|
||||
# like: binaries.20010814.13:42:16.tar.gz
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
# generic.sample.buildcf - this is an example buildcf which should be
|
||||
# useful to most people. Your needs may be different from this script
|
||||
# especially if you are running builds on many different OS platforms
|
||||
# especially if you are running builds on many different OS and platforms
|
||||
# which require different command sequences. Each build type
|
||||
# (construct, test, lint) defines a sequence of commands which is the
|
||||
# same on all build machines. They types each have different commands
|
||||
@@ -11,7 +11,7 @@
|
||||
# on the tinderbox server for each type of build. This cf file will
|
||||
# need a copy of the TreeData file on the build machine in order to
|
||||
# translate the treename into the name of the module and branch and
|
||||
# correctly set the CVSROOT environemental variable.
|
||||
# correctly set the CVSROOT environment variable.
|
||||
|
||||
# Run:
|
||||
|
||||
@@ -21,11 +21,11 @@
|
||||
--tree seamonkey
|
||||
|
||||
# to see the completed build script which has all the perl
|
||||
# vairiables substituted.
|
||||
# variables substituted.
|
||||
|
||||
|
||||
# $Revision: 1.4 $
|
||||
# $Date: 2001-11-14 21:22:13 $
|
||||
# $Revision: 1.5 $
|
||||
# $Date: 2002-01-02 18:09:58 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/befator/cvs/jail/cvsroot/mozilla/webtools/tinderbox2/src/clientbin/generic.sample.buildcf,v $
|
||||
# $Name: not supported by cvs2svn $
|
||||
@@ -112,7 +112,7 @@ sub filename_time_str {
|
||||
# The environmental variables for building at mozilla/netscape are
|
||||
# quite complicated, your needs may be much simpler. Putting all
|
||||
# environmental variable differences into a single function makes it
|
||||
# clearer exactly how the environment differes on different platforms.
|
||||
# clearer exactly how the environment differs on different platforms.
|
||||
|
||||
sub build_environment{
|
||||
|
||||
@@ -151,7 +151,7 @@ sub build_scripts {
|
||||
# pick a time earlier then the current time. Check out the sources
|
||||
# as of that time and use that time as the name of the tar
|
||||
# file. Now anyone who wants to recreate the sources of the binary
|
||||
# tar can use the tarfile name to checkout the souces as if we had
|
||||
# tar can use the tarfile name to checkout the sources as if we had
|
||||
# tagged them. We use a few minutes ago as the checkout time to
|
||||
# ensure that the CVS server has time to settle down from any
|
||||
# large checkins which may be in progress.
|
||||
@@ -198,7 +198,7 @@ sub build_scripts {
|
||||
$ENV{'BUILD_MODULE'} = $module;
|
||||
|
||||
|
||||
# builds discribe a sequence of steps needed to perform a "build".
|
||||
# builds describe a sequence of steps needed to perform a "build".
|
||||
# Each build either succeeds or fails. Builds can be used for running
|
||||
# tests and checking source code style in addition to creating binaries.
|
||||
|
||||
@@ -218,12 +218,12 @@ sub build_scripts {
|
||||
|
||||
# Each phase must have the following entries:
|
||||
|
||||
# phase_name: which discribes what the phase is.
|
||||
# phase_name: which describes what the phase is.
|
||||
|
||||
# error_status: the tinderbox status which should be returned
|
||||
# if the phase fails.
|
||||
|
||||
# script: a list of shell commands to be exectued in order
|
||||
# script: a list of shell commands to be executed in order
|
||||
# until one fails (each command in a separate shell, similar to make).
|
||||
|
||||
# dir: the directory which will be local while the script is
|
||||
@@ -339,8 +339,8 @@ sub error_parser_name {
|
||||
# hostname and OS name (and a few other details). We are running the
|
||||
# same build instructions on each architecture so it makes sense to
|
||||
# speak of the 'Solaris Build'. Other users who do not worry about
|
||||
# porability may use the buildscript buildname. These users will have
|
||||
# tinderbox colums with names like: "seamonkey", "grendel", "aurora"
|
||||
# portability may use the buildscript buildname. These users will have
|
||||
# tinderbox columns with names like: "seamonkey", "grendel", "aurora"
|
||||
# (these are the names of the 'type' of build).
|
||||
|
||||
sub build_name {
|
||||
|
||||
@@ -7,8 +7,8 @@
|
||||
# module which uses this library is: lib/TinderDB/VC_Bonsai.pm
|
||||
|
||||
|
||||
# $Revision: 1.6 $
|
||||
# $Date: 2001-08-13 19:50:46 $
|
||||
# $Revision: 1.7 $
|
||||
# $Date: 2002-01-02 18:09:56 $
|
||||
# $Author: kestes%walrus.com $
|
||||
# $Source: /home/befator/cvs/jail/cvsroot/mozilla/webtools/tinderbox2/src/lib/BonsaiData.pm,v $
|
||||
# $Name: not supported by cvs2svn $
|
||||
@@ -74,7 +74,7 @@ sub load_bonsai_libs {
|
||||
# bonsai must be both loaded and run from the bonsai dir.
|
||||
|
||||
chdir ($BONSAI_DIR) ||
|
||||
die("Could not cd to /. $!\n");
|
||||
die("Could not cd to $BONSAI_DIR. $!\n");
|
||||
|
||||
# Hide the use libs from the perl compiler. This is neccessary or
|
||||
# it will be evaluated before BONSAI_DIR is defined.
|
||||
|
||||
Reference in New Issue
Block a user