.\" -*-nroff-*-
.\"
-.\" $Id: sw.1,v 1.1 1999/06/02 16:53:33 mdw Exp $
+.\" $Id: sw.1,v 1.2 1999/06/04 13:56:09 mdw Exp $
.\"
.\" Manual page for `sw'
.\"
.\"----- Revision history ---------------------------------------------------
.\"
.\" $Log: sw.1,v $
-.\" Revision 1.1 1999/06/02 16:53:33 mdw
-.\" Initial revision
+.\" Revision 1.2 1999/06/04 13:56:09 mdw
+.\" Changes, extensions, polishings, spelling fixes...
+.\"
+.\" Revision 1.1.1.1 1999/06/02 16:53:33 mdw
+.\" Initial import.
.\"
.\"
.\" --- Useful macro definitions ---
.\"
-.de VS
+.de VS \" Start a sort-of verbatim block
.sp 1
.in +5n
.nf
.ft B
..
-.de VE
+.de VE \" Stop a sort-of verbatim block
.ft R
.fi
.in -5n
.sp 1
..
+.de HP \" Start an indented paragraph with a bold right-aligned label
+.IP
+\fB\h'-\w'\\$1\ 'u'\\$1\ \fP\c
+..
.\"
-.\" --- Style hacking for `groff' ---
+.\" --- Style hacking ---
.\"
.ie \n(.g \{\
. fam P
-. de MW
-\fR[\f(BImdw\fR]
-..
-.\}
-.el \{\
-. de MW
-\fR[\fBmdw\fR]
-..
+. ds mw \fR[\f(BImdw\fR]
.\}
+.el .ds mw \fR[\fBmdw\fR]
+.ie t .ds o \(bu
+.el .ds o o
+.ds sw \fBsw\fP
.\"
.\" --- Main manual text ---
.\"
.\"
.SH SYNOPSIS
.nf
-\fBsw --help
-\fBsw --help-full
-\fBsw --version
-\fBsw --archname
-\fBsw --remote \fIcommand
+\fBsw \-\-help
+\fBsw \-\-help-full
+\fBsw \-\-version
+\fBsw \-\-archname
+\fBsw \-\-remote \fIcommand
-\fBsw all-arch
+\fBsw all\-arch
\fBsw arch
-\fBsw \fR[\fB\-fbi\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] [\fB\-o \fIstyle\fR] \fBconfigure \fR[\fIconfgure-arg\fR...]
+\fBsw commit
+\fBsw \fR[\fB\-fbi\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] [\fB\-o \fIstyle\fR] \fBconfigure \fR[\fIconfigure-arg\fR...]
\fBsw host \fIarch
\fBsw \fR[\fB\-f\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] \fBlinktree
\fBsw listarch
\fBsw \fR[\fB\-fbi\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] [\fB\-o \fIstyle\fR] \fBmake \fR[\fImake-arg\fR...]
-\fBsw only-arch \fIarch \fR[\fIarch\fR...]
+\fBsw only\-arch \fIarch \fR[\fIarch\fR...]
\fBsw reset
\fBsw rsh \fIhost\fR|\fIarch \fR[\fIcommand \fR[\fIargument\fR...]]
\fBsw \fR[\fB\-fbi\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] [\fB\-o \fIstyle\fR] \fBrun \fIcommand \fR[\fIargument\fR...]
.\"
.\"
.SH "INTRODUCTION"
-The
-.B sw
-tool attempts to take a lot of the work out of building and installing
-source packages across multiple architectures. This section will
-describe how to use
-.BR sw 's
-features to best advantage in a number of common situations.
+The \*(sw tool attempts to take a lot of the work out of building and
+installing source packages across multiple architectures. This section
+will describe how to use \*(sw's features to best advantage in a number
+of common situations.
.PP
To keep things concrete, I'll describe how things are done at the EBI,
-although there's nothing EBI-specific about the
-.B sw
-program itself. For details about how we handle software at EBI, see
-the
+although there's nothing EBI-specific about the \*(sw program itself.
+For details about how we handle software at EBI, see the
.B Local quirks
section below.
.PP
.\"
.SH "SUMMARY OF BUILDING PACKAGES"
First, the
-.B autoconf
+.B Autoconf
case:
.VS
.BI "sw setup " "package version"
sw commit
.VE
Secondly, the
-.RB non- autoconf
+.RB non- Autoconf
case:
.VS
.BI "sw setup " "package version"
to refer to its version number.
.PP
Not all the important features and options are described in this part of
-the manual. View it more as a taster for the sorts of things
-.B sw
-can do, and a suggestion
+the manual. View it more as a taster for the sorts of things \*(sw can
+do, and a suggestion
.SS "1. Download the source distribution"
Download the package's source distribution. This will normally be in an
archive called something like
.VE
When you've finished unpacking, make sure that your current directory is
the top level directory of the source tree you unpacked.
-.SS "3. Tell sw what you're up to"
-Now you need to tell
-.B sw
-what you're working on. It will keep track of this and other bits of
-information in a little file and refer to it every now and then. It
-will also whinge at you and refuse to cooperate if it can't find its
-little file, so it's as well to oblige.
+.SS "3. Tell \\*(sw what you're up to"
+Now you need to tell \*(sw what you're working on. It will keep track of
+this and other bits of information in a little file and refer to it
+every now and then. It will also whinge at you and refuse to cooperate
+if it can't find its little file, so it's as well to oblige.
.PP
-To tell
-.B sw
-to create this little file and initialize it with sensible values, you
-just need to say
+To tell \*(sw to create this little file and initialize it with sensible
+values, you just need to say
.VS
.BI "sw setup " "package version"
.VE
wasn't sufficiently good at writing portable software, or because the
program's doing inherently nonportable things.
.PP
-If that's the case, then
-you need to tell
-.B sw
-to only build on the architectures that really work. Do this with the
+If that's the case, then you need to tell \*(sw to only build on the
+architectures that really work. Do this with the
.RB ` "sw only" '
command. For example, if your package only works on Linux and Solaris,
say:
.VS
sw only i386-linux sparc-solaris
.VE
-You can get a list of the architecture names that
-.B sw
-understands by typing
+You can get a list of the architecture names that \*(sw understands by
+typing
.VS
sw listarch
.VE
need to do anything for this step. Skip on to the next one.
.SS "5. Configure the package"
Now it gets complicated. If the package you're building uses
-.B autoconf
+.B Autoconf
to configure itself for its current environment then you're in luck.
You can tell an
-.B autoconf
+.B Autoconf
package because there's a script called
.B configure
in the top source directory, and a file called
If it
.I does
use
-.B autoconf
+.B Autoconf
then run
.VS
sw configure
If the package
.I doesn't
use
-.B autoconf
+.B Autoconf
then all is not lost (although it may be worthwhile complaining at the
package's author or maintainers). You need to make a collection of
.IR "link trees" ,
.VE
and waiting for a while. If you had the
.B curses
-library available when
-.B sw
-was built, then your terminal will split itself into little
-independently scrolling windows showing you the progress for each
-architecture. If you're not privileged enough to have
+library available when \*(sw was built, then your terminal will split
+itself into little independently scrolling windows showing you the
+progress for each architecture. If you're not privileged enough to have
.B curses
then you get the output appropriately tagged with architecture names,
which is unfortunately fairly hard to read.
.SS "7. Install the package"
Most source packages (and almost certainly all
-.B autoconf
+.B Autoconf
ones) have a
.B make
target
.RB ` install '
-which installs the program correctly. You can run this from
-.B sw
-by saying
+which installs the program correctly. You can run this from \*(sw by
+saying
.VS
sw \-i make install
.VE
The little
.RB ` \-i '
-option there tells
-.B sw
-that this is the
+option there tells \*(sw that this is the
.IR "install step" .
When an architecture completes this step correctly, it's marked as being
-properly installed, and
-.B sw
-doesn't bother thinking about it again.
+properly installed, and \*(sw doesn't bother thinking about it again.
.PP
If you
.I don't
.VS
sw -i run true
.VE
-just to tell
-.B sw
-that you've installed everything OK. (This is a bit of a kludge.)
+just to tell \*(sw that you've installed everything OK. (This is a bit
+of a kludge.)
.SS "8. Update the index"
Now that everything's built and installed, there's just one more command
to type:
.VS
sw commit
.VE
-This makes
-.B sw
-update its main index of installed packages, telling it which
-architectures packages are installed on, and who did it.
+This makes \*(sw update its main index of installed packages, telling it
+which architectures packages are installed on, and who did it.
.\"
.\"
.SH "REFERENCE INTRODUCTION"
to read the available help text. There's quite a lot of it, and it
ought to keep you occupied for a while.
.PP
-The basic
-.B sw
-command line looks a bit like:
+The basic \*(sw command line looks a bit like:
.sp 1
-.RS 5
-.B sw
+.RS 5
+.B sw
.RI [ options ]
.RI [ command
.RI [ argument ...]]
.VS
sw
.VE
-at the shell prompt,
-.B sw
-gives you an extremely terse usage summary and quits. You have to tell
-it to do
+at the shell prompt, \*(sw gives you an extremely terse usage summary
+and quits. You have to tell it to do
.IR something .
-Most of the time you do this by giving
-.B sw
-a
+Most of the time you do this by giving \*(sw a
.IR command ,
like
.RB ` setup '
or
.RB ` make '
so that it knows what to do. There are some strange command line
-options which cause
-.B sw
-to do more exotic things, though.
+options which cause \*(sw to do more exotic things, though.
.\"
.\"
.SH "IMPLEMENTATION ODDITIES"
-The
-.B sw
-program that users use is really a small architecture-neutral shell
-script, which works out the current architecture and executes the
+The \*(sw program that users use is really a small architecture-neutral
+shell script, which works out the current architecture and executes the
appropriate architecture-specific main program. It's done this way so
-that
-.B sw
-knows that it can use the shell script to start itself up on a remote
-host with a different architecture, something which it does quite a
-lot. The only feature provided by the front-end shell script is the
+that \*(sw knows that it can use the shell script to start itself up on
+a remote host with a different architecture, something which it does
+quite a lot. The only feature provided by the front-end shell script is
+the
.B \-\-archname
-command line option, which shouldn't be used by anyone except
-.BR sw 's
-build procedure anyway.
+command line option, which shouldn't be used by anyone except \*(sw's build procedure anyway.
.\"
.\"
.SH "COMMAND LINE OPTION REFERENCE"
-Any
-.B sw
-command line options can be put in the
+Any \*(sw command line options can be put in the
.B SW
-environment variable. The
-.B sw
-program will read space-separated options from this variable before it
-reads the command line itself.
+environment variable. The \*(sw program will read space-separated
+options from this variable before it reads the command line itself.
.PP
-The
-.B sw
-program usually understands two different names for each option: a
-traditional Unix single-character name, and a long GNU-style name. The
-short options behave in the normal Unix way: you can join them together
-into single words with a
+The \*(sw program usually understands two different names for each
+option: a traditional Unix single-character name, and a long GNU-style
+name. The short options behave in the normal Unix way: you can join
+them together into single words with a
.RB ` \- '
at the front, for example. The long names are always preceded by a
double dash. You can abbreviate long names as much as you like, as long
below, both the short and long names of the options are shown, but for
reasons of brevity required arguments are only shown for the long form.
.PP
-There are conceptually two types of
-.B sw
-command line options: those which, usually for reasons of consistency
-with other programs, cause
-.B sw
-to do something immediately; and those which store some settings for
-particular commands. The latter type are generally more useful. It's
-worth bearing in mind, though, that the options are only used by a few
-commands. The command reference describes exactly which commands use
-which options.
+There are conceptually two types of \*(sw command line options: those
+which, usually for reasons of consistency with other programs, cause
+\*(sw to do something immediately; and those which store some settings
+for particular commands. The latter type are generally more useful.
+It's worth bearing in mind, though, that the options are only used by a
+few commands. The command reference describes exactly which commands
+use which options.
.PP
The complete list of command line options understood by the current
-version of
-.B sw
-is as follows:
+version of \*(sw is as follows:
.TP
.B "\-h, \-\-help"
-Writes a fairly brief summary of
-.BR sw 's
-command line options and a usage line for each of
-.BR sw 's
-commands to standard output, and exits successfully.
+Writes a fairly brief summary of \*(sw's command line options and a usage line for each of \*(sw's commands to standard output, and exits successfully.
.TP
.B "\-H, \-\-help\-full"
-Writes a summary of
-.BR sw 's
-command line options and a full paragraph of description for each of
-.BR sw 's
-commands to standard output, and exits successfully. There's a lot of
+Writes a summary of \*(sw's command line options and a full paragraph of description for each of \*(sw's commands to standard output, and exits successfully. There's a lot of
text generated by this option. I recommend you pipe it through a pager
so that you can actually read it.
.TP
.B "\-v, \-\-version"
-Writes
-.BR sw 's
-version number to standard output and exits successfully. This is handy
-when trying to decide whether your version of
-.B sw
-has a particular feature, for example.
+Writes \*(sw's version number to standard output and exits successfully. This is handy
+when trying to decide whether your version of \*(sw has a particular feature, for example.
.TP
.B "\-u, \-\-usage"
Writes a usage message so terse as to be nearly useless to standard
output and exits successfully. This is different from just running
.RB ` sw '
-because although both print the same useless message, running
-.B sw
-without any arguments is considered an error, so the message is sent to
-standard error and
-.B sw
-will exit unsuccessfully.
+because although both print the same useless message, running \*(sw without any arguments is considered an error, so the message is sent to
+standard error and \*(sw will exit unsuccessfully.
.TP
.BI "\-a, \-\-arch " arch , arch\fR...
For commands which affect multiple architectures: only affect the
architectures specified. The architecture names may be separated by
commas, spaces or both, although clearly commas are most convenient on
-the command line. This option overrides any other decisions that
-.B sw
-might make about which architectures to process based on the
-.B only-arch
+the command line. Architecture names may be abbreviated as long as the
+abbreviation is not ambiguous.
+.IP
+This option overrides any other decisions that \*(sw might make about which architectures to process based on the
+.B only\-arch
list and the list of correctly built architectures for the current
package.
.TP
waiting for a long build.
.PP
The remaining options aren't really intended for users. They're helpful
-for
-.BR sw 's
-own purposes, though, and described here for completeness' sake. They
+for \*(sw's own purposes, though, and described here for completeness' sake. They
don't have standard Unix short name equivalents, because they're not
usually useful for users.
.TP
.B "\-\-archname"
-Writes the
-.B sw
-architecture name of the current host to standard output. This is used
-by
-.BR sw 's
-configuration script to determine the current architecture name. This
+Writes the \*(sw architecture name of the current host to standard output. This is used
+by \*(sw's configuration script to determine the current architecture name. This
option is actually handled by a small shell script rather than by being
passed on to the main program. You shouldn't use this option yourself:
use the
.RB ` \-\-a '.
.TP
.BI "\-\-me " name
-Sets
-.BR sw 's
-idea of its program name to
+Sets \*(sw's idea of its program name to
.IR name .
-This is intended for use by
-.BR sw 's
-front-end shell script, but isn't actually needed at the moment. I
-can't see why you'd want to play with this option, but it shouldn't do
-any harm.
+This is intended for use by \*(sw's front-end shell script, but isn't
+actually needed at the moment. I can't see why you'd want to play with
+this option, but it shouldn't do any harm.
.TP
.BI "\-\-remote " remote-command
-Used by
-.B sw
-when running commands on remote hosts. Don't use this yourself: it puts
-.B sw
-into a very unfriendly mode and requires that you communicate with it
+Used by \*(sw when running commands on remote hosts. Don't use this yourself: it puts \*(sw into a very unfriendly mode and requires that you communicate with it
using a bizarre binary packet protocol. If you really must know more
about this, see the source code: it's quite well documented, really.
.\"
.\"
-.SH "COMMAND REFERENCE"
-.SS Terminology
+.SH TERMINOLOGY
The descriptions below make use of some technical terms:
.TP
.B "architecture restriction"
.RB ` \-a '
command line option, are affected by a
.IR "build command" .
-To determine the default build architectures,
-.B sw
-reads the list of all architectures from the
+To determine the default build architectures, \*(sw reads the list of all architectures from the
.B archtab
file, and filters it: if the
.RB ` \-f '
.B reset
command. The
.RB ` \-f '
-option causes
-.B sw
-to ignore whether architectures have been successfully built when
+option causes \*(sw to ignore whether architectures have been successfully built when
determining the
.IR "default build architectures" .
-.bp
-This section describes all of the available
-.B sw
-commands, in alphabetical order.
+.SH "COMMAND REFERENCE"
+This section describes all of the available \*(sw commands, in alphabetical order.
.\"
-.SS all-arch
-.PP
+.SS all\-arch
Clears an architecture restriction set by
-.RB ` only-arch '.
+.RB ` only\-arch '.
Subsequent build commands will run across all known architectures not
yet successfully built, unless overridden by the
.RB ` \-a '
command-line option, or a later
-.RB ` only-arch '
+.RB ` only\-arch '
command.
.\"
.SS arch
Writes the name of the local host's architecture to standard output.
-The architecture name is built into
-.B sw
-at compile time.
+The architecture name is built into \*(sw at compile time.
+.SS commit
+Writes information from the
+.B .sw\-info
+file to the installed packages index file
+.IB prefix /sw-index\fR.
+.PP
+All expected architectures must be built before a commit will work.
.\"
.SS configure \fR[\fIconfigure-arg\fR...]
+Equivalent to the command
+.VS
+.BI "run ../configure \-\-prefix=" prefix " " configure-arg\fR...
+.VE
+where
+.I prefix
+is the installation prefix with which \*(sw itself was configured. If you want to specify a different prefix, pass
+your own
+.B \-\-prefix
+argument.
+.PP
+It is expected that administrators will set up a file
+.IB prefix /share/config.site
+which sets up other Autoconf parameters once the prefix has been
+chosen. See the Autoconf manual for more information.
.\"
.SS host \fIarch\fR
Writes to standard output the name of a host with requested architecture
other.
.PP
If the link trees already exist, then rerunning
-.B linkfree
+.B linktree
will update the links. This might be useful if the links somehow become
invalid.
.PP
file.
.\"
.SS make \fR[\fImake-arg\fR...]
+Equivalent to
+.VS
+.BI "run make " make-arg\fR...
+.VE
+in all respects.
.\"
-.SS only-arch \fIarch arch\fR...
+.SS only\-arch \fIarch arch\fR...
+Imposes an architecture restriction. Until cancelled by a later
+.B only\-arch
+or
+.B all\-arch
+command, the default build architectures will be limited to the
+architectures listed on the command line. Architecture names may be
+abbreviated as long as the abbreviation is not ambiguous.
+.\"
+.SS reset
+Clears the
+.I "successfully built"
+status of all architectures.
.\"
.SS rsh \fIhost\fR|\fIarch \fR[\fIcommand \fR[\fIargument\fR...]]
+Runs
+.I command
+on a remote host, passing it the list of
+.IR argument s.
+The
+.B "sw rsh"
+command is unlike the standard
+.B rsh
+program and its replacements:
+.HP \*o
+The
+.I command
+and
+.IR argument s
+are not subjected to further shell expansion on the remote host.
+.HP \*o
+The command is run with the remote current directory the same as the
+local current directory, rather than the remote user's home directory.
+.HP \*o
+The command is passed an environment constructed from the local
+environment, the default remote environment, and
+.B sw\-env
+files, as described in the section
+.B "Remote environment"
+below.
+.HP \*o
+The remote command is run with standard input attached to
+.BR /dev/null :
+there is no way of running an interactive remote command through
+.BR sw.
+.PP
+The host on which to run the remote command may be specified as one of:
+a standard host name (or IP address), an architecture name (which may
+.I not
+be abbreviated) signifying a host of the appropriate architecture, or
+the special name
+.RB ` \- '
+signifying the current host. (This last option may not sound useful,
+but it's handy for testing.)
.\"
.SS run \fIcommand \fR[\fIargument\fR...]
+Runs a command on all build architectures.
+.PP
+For each build architecture
+.IR arch ,
+\*(sw finds a host with the appropriate architecture, by choosing either
+the local host or reading the hostname from the
+.B archtab
+file. It then performs the following actions on that host:
+.HP 1.
+Sets the current directory to be the subdirectory named
+.I arch
+of the directory from which the command was issued. This directory is
+created if it doesn't already exist.
+.HP 2.
+Sets up an environment constructed from the environment prevailing when
+the command was issued, the default environment set up by
+.B rsh
+(or whatever equivalent remote execution program was actually used), and
+the
+.B sw\-env
+files, as described in the section
+.B "Remote environment"
+below.
+.HP 3.
+Executes the program named
+.I command
+passing it the given
+.IR argument s.
+.PP
+Output from the command is both appended to the file
+.IB arch/.build-log
+and output in some
+.IR "output style" ,
+as specified by the
+.RB ` \-o '
+command-line option. See the section
+.B "Output styles"
+below for more details.
+.PP
+If the
+.RB ` \-i '
+option was given on the command line, each architecture on which the
+command succeeds (i.e., reports a zero exit code) is marked as
+.IR "successfully built" ,
+and further build commands will not affect it unless the
+.RB ` \-f '
+command line option is passed, until a
+.B reset
+command is performed.
.\"
.SS setup \fIpackage version \fR[\fImaintainer\fR]
+Sets up various pieces of information required by \*(sw. The
+information here will be added into the main index file by a
+.B commit
+command. The information is maintained in a file named
+.B .sw\-info
+in the current directory.
+.PP
+The
+.I package
+should be the basic name of the package, with versioning information
+stripped off, e.g.,
+.RB ` emacs '
+or
+.RB ` perl ',
+not
+.RB ` emacs\-19.34 '.
+The
+.I version
+should be the version number of the package. The
+.I maintainer
+should be the name of the person principally responsible for maintaining
+the package's local installation. If this isn't specified, the calling
+user's name is used as the maintainer.
+.PP
+The
+.B setup
+command must be run before any build command.
.\"
.SS snaplink \fIfile \fR[\fIfile\fR...]
-Creates archtitecture-specific versions of a file. For each build
-architecture
-.I arch
-and file
-.IR file ,
-.B sw
-creates a copy
-.IB arch / file\c
-, replacing
-.\"
-.SS status
-foo
-.\"
-.\"
-.\"
-.\"
-.\"
-.\"
-.\"
-.\"
-.\"
-.\"
-.\"
-.\"
-.bp
-.\"
+Creates architecture-specific versions of a file. Every
+.I file
+named on the command line is copied to
+.IB arch / file
+for every build architecture
+.IR arch ,
+overwriting any existing file or symbolic link of that name. If
+.I file
+contains leading directories then destination directories are created as
+necessary for the output files. Note that the `snap' operation doesn't
+actually need to follow creation of link trees.
+.\"
+.\"
+.SH "OUTPUT STYLES"
+Output from a build command is presented in one of a number of named
+.IR "output styles" .
The style name
.RB ` plain '
is always defined: it simply prefixes each line of output with the
name of the architecture which generated the line, which isn't actually
particularly easy to read. Other output styles may have been configured
-into
-.B sw
-when it was compiled.
+into \*(sw when it was compiled.
.PP
-The set of output styles supported by
-.B sw
-varies according to how it was configured. In any particular
-.B sw
-program, you might have some of the following:
+The set of output styles supported by \*(sw varies according to how it
+was configured. In any particular \*(sw program, you might have some of
+the following:
.TP
.B plain
Simply prefixes each output line with the name of the architecture it
.PP
The
.RB ` plain '
-style is always available. It's used when the selected style doesn't
-work (for example, you don't have a sufficiently capable terminal for
-curses output).
+style is used when the selected style doesn't work (for example, you
+don't have a sufficiently capable terminal for curses output).
.PP
Output style names can be abbreviated as long as the abbreviation is
-unambiguous.
+unambiguous. You can find the list of available output styles by
+executing the command
+.VS
+sw \-o help run
+.VE
+(which is a little counter-intuitive, I know).
.PP
The author has plans to implement an X-based output style, but hasn't
got around to it yet.
.\"
.\"
-.\"
-.\"
-.\"
-.\"
-.\"
-.\"
-.\"
-.\"
-.\"
-.\"
+.SH "REMOTE ENVIRONMENT"
+The environment for a remote command (executed either through the
+.B rsh
+command, or a build command) is set up as follows:
+.HP \*o
+The complete environment passed to \*(sw is used as a basis.
+.HP \*o
+Any environment variables defined by the remote execution program
+(usually
+.BR rsh )
+override corresponding variables in the basis environment.
+.HP \*o
+Variable assignments are read from the global
+.IB prefix /share/sw\-env
+file. This makes some assignments which are useful everywhere, and will
+then usually include the file
+.B .sw\-env
+in the current directory.
+.PP
+The format of the
+.B sw\-env
+files is documented separately in
+.BR sw\-env (5).
.\"
.\"
.SH ENVIRONMENT
are read before, and overridden by, the actual arguments given on the
command-line.
.TP
+.B SW_MAKE
+The name of the command to use to run a `make'. This is resolved on the
+local host once, rather than one for each build host, which is probably
+a misfeature. To do something more clever, point
+.B SW_MAKE
+at a shell script which then picks out the right architecture-specific
+.RB ` make '
+program from the remote environment.
+.TP
.B SW_RSH
The name of the remote-shell program to use. By default, something
similar to
The following files are of interest to
.BR sw :
.TP
-.IB prefix /sw-index
+.IB prefix /sw\-index
The main index file, containing the list of which packages have been
installed for which architectures. See
.BR sw-info (5)
.BR archtab (5)
for file format details.
.TP
-.IB prefix /share/sw-env
+.IB prefix /share/sw\-env
Contains global environment variable settings. See
.BR sw-env (5)
for file format details.
.TP
-.IB package /.sw-info
+.IB package /.sw\-info
Contains the persistent information about a particular package's build
status. See
.BR sw-info (5)
for file format details.
.TP
-.IB package /.sw-env
+.IB package /.sw\-env
Contains package-specific environment variable settings. See
.BR sw-env (5)
for file format details.
.TP
-.IB package / arch /.build-log
+.IB package / arch /.build\-log
Contains all the build output for a particular architecture. Usually
not very interesting, but might be handy one day.
.\"
.BR sw ,
merely unexpected behaviour modes. Silly you for thinking otherwise.
.SH AUTHOR
-The
-.B sw
-program, and this manual, are
-.MW
-productions, in association
-with the European Bioinformatics Instutute. They were written by Mark
+The \*(sw program, and this manual, are \*(mw productions, in association
+with the European Bioinformatics Institute. They were written by Mark
Wooding <mdw@nsict.org>. Go and ask him if you have problems.
.\"
.\"----- That's all, folks --------------------------------------------------
~mdw / sw-tools / commitdiff