Classic Shell Scripting - Arnold Robbins [114]
fi
done
}
The last function, build_one, is where the work for one package on one remote host is handled. It is long enough that we present it in parts:
build_one( )
{
# Usage:
# build_one [user@]host[:build-directory][,envfile]
Until now, apart from a brief mention in the comment banner, we have not precisely specified what is in the $HOME/.build/userhosts initialization file. We require up to four pieces of information: the username on the remote host (if different from that on the initiating host), the hostname itself, the name of the existing directory on the remote host where the build should take place, and possibly additional environment variable settings specific to this build. It isn't convenient in a shell script to maintain those pieces in separate lists, so we simply borrow syntax from the remote and secure shells and jam them together with separator characters, like this:
jones@freebsd.example.com:/local/build,$HOME/.build/c99
Only the hostname component is mandatory.
We need the parts as well, so we use echo and sed to split the argument apart. Passing the argument through eval expands any environment variables in the name (like HOME in $HOME/.build/c99), avoiding the need to hardcode system-specific login directory paths in the userhosts files. For convenience, we provide a default build directory of /tmp if one was not specified:
arg="`eval echo $1`" Expand env vars
userhost="`echo $arg | sed -e 's/:.*$//'`" Remove colon and
everything after it
user="`echo $userhost | sed -e s'/@.*$//'`" Extract username
test "$user" = "$userhost" && user=$USER Use $USER if empty
host="`echo $userhost | sed -e s'/^[^@]*@//'`" Extract host part
envfile="`echo $arg | sed -e 's/^[^,]*,//'`" Name of env vars file
test "$envfile" = "$arg" && envfile=/dev/null
builddir="`echo $arg | sed -e s'/^.*://' -e 's/,.*//'`" Build directory
test "$builddir" = "$arg" && builddir=/tmp
We would prefer one of the nonvolatile temporary directories for builddir, but Unix vendors disagree on what they are called. A few extra lines of code could make a suitable test, but we assume that most users will specify a sensible build directory. Besides the fact that /tmp is usually cleared upon a reboot, there are other reasons why /tmp is not a good choice for builddir:
On many systems, /tmp is a separate filesystem that is too small to hold the build tree for a large package.
On some systems, /tmp is mounted without permission to execute programs in it: that may cause configure tests and validation checks to fail.
Under several releases of Sun Solaris, for unknown reasons native compilers could not compile code in /tmp.
The envfile facility is essential: it allows us to override defaults chosen by configure. Software developers should test their code with as many compilers as possible to verify portability and ferret out bugs. By choosing different build directories and envfile values, we can do multiple simultaneous builds on the same host with different compilers. The envfile files are quite simple: they just set environment variables, like this:
$ cat $HOME/.build/c99
CC=c99
CXX=CC
The next step in our program is to save the bare filename (e.g., gawk-3.1.4.tar.gz) in the variable parbase:
parbase=`basename $PARFILE`
The package name (e.g., gawk-3.1.4) is saved in the variable package:
package="`echo $parbase | \
sed -e 's/[.]jar$//' \
-e 's/[.]tar[.]bz2$//' \
-e 's/[.]tar[.]gz$//' \
-e 's/[.]tar[.]Z$//' \
-e 's/[.]tar$//' \
-e 's/[.]tgz$//' \
-e 's/[.]zip$//'`"
We use explicit sed patterns to strip the suffixes: there are too many dots in the name to make a simpler pattern reliable. To ensure that they work with older sed implementations, we specify them in separate substitution commands, instead of in a single extended regular expression. Should support for new archive formats ever be added to find_package, these editor patterns need to be updated as well.
The next step is to copy the archive file to the build directory on the remote host, unless it can already