Introduction
============
This directory contains scripts used to build and test zmap.
The scripts can be run by hand but are also run from a crontab so be careful
when changing them !
If you add scripts to this directory then here are some points to note:
1) scripts must either be perl or bash, i.e. not sh, csh, awk or ksh.
2) If you write a bash script then you should make use of the general
functions and variables in the ZBfunctions script file. This file is
now being phased out in favour of a separate zmap_functions.sh and
build_config.sh. zmap_functions.sh holds the common functions as
ZBfunctions did, but not the variables. The build_config.sh and its
fellows take care of the setting of common variables now.
3) The scripts get copied to ~zmap/prefix/scripts which the zmap
developers and the zmap userid have on their path. While this is where your
script will be found, you should not assume that this is where your script
will be running from.
4) pipes over ssh are utilised quite a bit in the build_bootstrap.sh script.
These can be spotted as code that looks similar to
cat $script | ssh $host '/bin/bash -c "\
cd /var/tmp || exit 1;\
cat - > host_checkout.sh || exit 1;\
chmod 755 host_checkout.sh || exit 1;\
./host_checkout.sh || exit 1;\
rm -f host_checkout.sh || exit 1;\
"' > $host.log 2>&1
This enables 3 important features:
- a reasonably atomic run of the script on the remote host,
- no dependecies on the remote host,
- complete, simple logging of everything going on, on the remote host.
Indeed the build_bootstrap.sh script is run in the same manner by the
zmap_overnight.sh and zmap_do_build.sh scripts. This is possible as the
bootstrap script does the checking out from cvs and produces the code
that runs on the various building hosts.
Overview of scripts
===================
********************** N.B. ***************************
Some of these are now obsolete. I've been updating the build scripts
to alter the logic and where they get configuration from. The
ZBfunctions method didn't quite work well enough when it came to
running on multiple architectures. It has been replaced with
zmap_functions.sh and build_config.sh. build_config.sh tries to load
build_config.$(uname).sh and build_config.$(hostname -s).sh to be more
flexible in terms of architecture and machine configuration
differences. Additionally there are a small number of cover scripts
to do various types of build.
- zmap_overnight.sh - run by cron and contains all the config options
so the crontab can be simple. cron.log is only
for errors that might occur before internal log
file gets created.
00 23 * * * ~/prefix/scripts/zmap_overnight.sh > ~/BUILDS/cron.log 2>&1
- zmap_do_build.sh - script to run what was zmapbuild cmd line in how
to build a release (below)
********************** N.B. ***************************
Scripts cover the following tasks:
Task Script
-------------------------------------------------- ------------------------
Get lastest CVS copy of Ace-Con package
used by zmap, compile and put libs in buildaceconn
correct ~zmap/prefix/XXXX/lib dirs.
Make a zmap release directory containing
a consistent set of zmap and acedb binaries zmap_release.sh
from ~zmap/prefix/XXXX/bin
Copy the required acedb binaries from an zmap_fetch_acedbbinaries.sh
acedb release directory into ~zmap/prefix/XXXX/bin
Interrogate/Set release version of zmap source code versioner
Set up common functions/variables for all scripts ZBfunctions
in this directory. (deprecated)
Update ~zmap/prefix/scripts to latest code and zmap_overnight.sh
optionally run a command using the shell script. zmap_do_build.sh
Can be run as a cron job... Care needed when editing.
Do a complete build of zmap on various machines build_bootstrap.sh
using ssh.
Produce zmap documentation for website etc. zmap_make_docs.sh
Set symbolic links in ~zmap that point to zmap_symlink.sh
OVERNIGHT, DEVELOPMENT & RELEASE dirs.
Compile zmap on a specific machine and zmap_build_and_tar.sh
optionally test that it runs.
Update the zmap web development site and zmap_update_web.sh
optionally update the external website.
How to build a new release
==========================
********************** N.B. ***************************
See zmap_do_build.sh instead now. (does a release with incremented
update version)
build_config.sh etc can alter the behaviour.
e.g. to use an acedb level other than DEVELOPMENT (the default) set
ZMAP_ACEDB_RELEASE_DIR=
to point to the XXXXXX part of the ~acedb/RELEASE.XXXXXXX directory
that you want to use. In most cases you need to edit the file but
for the acedb release you can simply set the variable on the command
line, see below.
********************** N.B. ***************************
Each time we build a new release of zmap we tag the release so we can recreate
the code from cvs at any time. We also update the version number held in the
code itself so that all the next development session takes place with this
new code version number for bug reporting etc.
And we also create a set of release notes which need to be hand editted afterwards,
they live in ZMap/doc/Release_notes, the -d flag tells zmapbuild to call
zmapreleasenotes to make the notes.
Currently this is what you need to do to make such a release...
As user "zmap":
> cd ~/prefix/scripts
> ./zmap_do_build.sh
to use a particular acedb release (assuming bash):
> ZMAP_ACEDB_RELEASE_DIR=2009_10_20 ; ./zmap_do_build.sh
The versioner script
====================
Roy wrote the versioner script which is used to do all sorts of version like stuff...
# here's how to get the version number for setting up a directory name...this is already
# in the script....
deskpro16113[edgrif]54: versioner -path $HOME/ZMap/ZMap/src/include/ZMap/ -show -V -quiet
0-1-3
# heres how to get the tag....
deskpro16113[edgrif]55: versioner -path $HOME/ZMap/ZMap/src/include/ZMap/ -show -quiet
RELEASE_0-1-3
the script can also tag the whole of cvs...
edgrif
authored