Skip to content
Snippets Groups Projects
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...

versioner -path <your ZMap directory> -tag -increment -update -cvs


It can also be used to increment any file containing the zmap version strings such as
ZMap/src/include/ZMap/zmapXRemote.h, to do this on a locally cvs edited file without
tagging cvs etc do this:

versioner -increment -update -path <your ZMap directory> -file src/include/ZMap/zmapXRemote.h

e.g.

tviewsrv[edgrif]64: versioner -increment -update -path /nfs/team71/acedb/edgrif/ZMap/ZMap_Curr/ZMap/ -file src/include/ZMap/zmapXRemote.h
Using '/nfs/team71/acedb/edgrif/ZMap/ZMap_Curr/ZMap' as Checkout Directory.
The CVS tag should be RELEASE_1-1-3. 
RELEASE_1-1-3
Local Version is now RELEASE_1-1-4, previous version in /nfs/team71/acedb/edgrif/ZMap/ZMap_Curr/ZMap/src/include/ZMap/zmapXRemote.h.backup