5 .\" Manual page for `sw'
10 .\"----- Licensing notice ---------------------------------------------------
12 .\" This file is part of sw-tools.
14 .\" sw-tools is free software; you can redistribute it and/or modify
15 .\" it under the terms of the GNU General Public License as published by
16 .\" the Free Software Foundation; either version 2 of the License, or
17 .\" (at your option) any later version.
19 .\" sw-tools is distributed in the hope that it will be useful,
20 .\" but WITHOUT ANY WARRANTY; without even the implied warranty of
21 .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
22 .\" GNU General Public License for more details.
24 .\" You should have received a copy of the GNU General Public License
25 .\" along with sw-tools; if not, write to the Free Software Foundation,
26 .\" Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
28 .\"----- Style hacking ------------------------------------------------------
30 .de VS \" Start a sort-of verbatim block
36 .de VE \" Stop a sort-of verbatim block
42 .de hP \" Start an indented paragraph with a bold right-aligned label
44 \fB\h'-\w'\\$1\ 'u'\\$1\ \fP\c
49 . ds mw \fR[\f(BImdw\fR]
51 .el .ds mw \fR[\fBmdw\fR]
56 .\"----- Main manual text ---------------------------------------------------
58 .TH sw 1 "25 May 1999" sw-tools
61 .\"--------------------------------------------------------------------------
65 sw \- tool for convenient software installation
67 .\"--------------------------------------------------------------------------
76 \fBsw \-\-remote \fIcommand
81 \fBsw \fR[\fB\-fbip\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] [\fB\-o \fIstyle\fR] \fBconfigure \fR[\fIconfigure-arg\fR...]
83 \fBsw \fR[\fB\-f\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] \fBlinktree
85 \fBsw \fR[\fB\-fbip\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] [\fB\-o \fIstyle\fR] \fBmake \fR[\fImake-arg\fR...]
86 \fBsw only\-arch \fIarch \fR[\fIarch\fR...]
88 \fBsw rsh \fIhost\fR|\fIarch \fR[\fIcommand \fR[\fIargument\fR...]]
89 \fBsw \fR[\fB\-fbip\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] [\fB\-o \fIstyle\fR] \fBrun \fIcommand \fR[\fIargument\fR...]
90 \fBsw setup \fIpackage version \fR[\fImaintainer\fR]
91 \fBsw \fR[\fB\-f\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] \fBsnaplink \fIfile \fR[\fIfile\fR...]
96 .\"--------------------------------------------------------------------------
100 The \*(sw tool attempts to take a lot of the work out of building and
101 installing source packages across multiple architectures. This section
102 will describe how to use \*(sw's features to best advantage in a number
103 of common situations.
105 To keep things concrete, I'll describe how things are done at the EBI,
106 although there's nothing EBI-specific about the \*(sw program itself.
107 For details about how we handle software at EBI, see the
111 By the way, this is quite a large manual. I recommend that you print a
112 copy onto paper and peruse it in a leisurely fashion, rather than
113 squinting at a monitor.
115 .\"--------------------------------------------------------------------------
117 .SH "SUMMARY OF BUILDING PACKAGES"
123 .BI "sw setup " "package version"
125 .IR "arch " [ arch ...]
136 .BI "sw setup " "package version"
138 .IR "arch " [ arch ...]
141 .IR "file " [ file ...]
142 .I [edit the appropriate files]
149 .\"--------------------------------------------------------------------------
151 .SH "8 STEPS TO INSTALLING A PACKAGE"
153 The following steps will guide you through your first (and maybe second)
154 package installations. In the description, I'll use
156 to refer to the package's name, and
158 to refer to its version number.
160 Not all the important features and options are described in this part of
161 the manual. View it more as a taster for the sorts of things \*(sw can
163 .SS "1. Download the source distribution"
164 Download the package's source distribution. This will normally be in an
165 archive called something like
166 .IB package - version .tar.gz\c
167 \&. At EBI, we put source archive files in
169 .SS "2. Unpack the source tree"
170 Unpack the source tree into the standard source directory. Each source
171 tree should have its own directory. Most well-packaged source
172 distributions unpack themselves into a neat directory, but less
173 fastidious programmers make archives which scatter files all over the
176 At EBI, we put the source trees in
178 so unpacking a well-formed source distribution looks like:
181 .BI "gzip \-dc ../tr/" package \- version ".tar.gz | tar xfv \-"
183 Ill-formed source distributions involve making the directory for the
184 package first, changing into it, and then unpacking into the current
188 .BI "mkdir " package \- version
189 .BI "cd " package \- version
190 .BI "gzip \-dc ../../tr/" package - version ".tar.gz | tar xfv \-"
192 When you've finished unpacking, make sure that your current directory is
193 the top level directory of the source tree you unpacked.
194 .SS "3. Tell \\*(sw what you're up to"
195 Now you need to tell \*(sw what you're working on. It will keep track of
196 this and other bits of information in a little file and refer to it
197 every now and then. It will also whinge at you and refuse to cooperate
198 if it can't find its little file, so it's as well to oblige.
200 To tell \*(sw to create this little file and initialize it with sensible
201 values, you just need to say
203 .BI "sw setup " "package version"
205 What could be easier?
206 .SS "4. Restrict the build to particular architectures"
207 Some packages don't work on all architectures, either because the author
208 wasn't sufficiently good at writing portable software, or because the
209 program's doing inherently nonportable things.
211 If that's the case, then you need to tell \*(sw to only build on the
212 architectures that really work. Do this with the
214 command. For example, if your package only works on Linux and Solaris,
217 sw only i386-linux sparc-solaris
219 You can get a list of the architecture names that \*(sw understands by
224 With a little bit of luck, these names ought to be self-explanatory.
226 If your package is properly portable and works everywhere then you don't
227 need to do anything for this step. Skip on to the next one.
228 .SS "5. Configure the package"
229 Now it gets complicated. If the package you're building uses
231 to configure itself for its current environment then you're in luck.
234 package because there's a script called
236 in the top source directory, and a file called
246 to configure the package on all the platforms it's meant to be built
247 for. When you've done that, move onto the next step.
253 then all is not lost (although it may be worthwhile complaining at the
254 package's author or maintainers). You need to make a collection of
256 one for each architecture. These link trees are little replicas of the
257 main source tree but with symbolic links instead of the real source
258 files. To make the link trees, run
262 Now, that's not actually quite what you wanted. It's made a link for
264 file in the source tree. Unfortunately, there are some files you'll
265 (probably) have to modify for each architecture in order to configure
266 the package to build properly. You can turn links in the link trees
267 into real independently editable files by
269 the links. Say for example that
273 need to be modified for each architecture. Running the command
275 sw snaplink Makefile config.h
277 is sufficient to do the right thing.
279 Now you must edit the snapped files to configure the package. Make sure
280 that the install directories are correctly set. At EBI, all the
281 software should be configured so that architecture neutral files end up
284 and architecture-specific files end up under
285 .BI /sw/common/arch/ arch\c
287 .SS "6. Build the package"
288 Now you've laid the groundwork, everything ought to be easy. Making the
289 program ought to involve simply typing
293 and waiting for a while. If you had the
295 library available when \*(sw was built, then your terminal will split
296 itself into little independently scrolling windows showing you the
297 progress for each architecture. If you're not privileged enough to have
299 then you get the output appropriately tagged with architecture names,
300 which is unfortunately fairly hard to read.
301 .SS "7. Install the package"
302 Most source packages (and almost certainly all
308 which installs the program correctly. You can run this from \*(sw by
315 option there tells \*(sw that this is the
317 When an architecture completes this step correctly, it's marked as being
318 properly installed, and \*(sw doesn't bother thinking about it again.
324 makefile target, then you have to install things manually. That's not
325 much fun, so moan at the package's author. When you've finished
326 fiddling with installation, run
330 just to tell \*(sw that you've installed everything OK. (This is a bit
332 .SS "8. Update the index"
333 Now that everything's built and installed, there's just one more command
338 This makes \*(sw update its main index of installed packages, telling it
339 which architectures packages are installed on, and who did it.
341 .\"--------------------------------------------------------------------------
343 .SH "REFERENCE INTRODUCTION"
345 That was a gentle introduction. This section contains the complete
348 far more detail that you probably want. If that's really the case, try
353 to read the available help text. There's quite a lot of it, and it
354 ought to keep you occupied for a while.
356 The basic \*(sw command line looks a bit like:
369 at the shell prompt, \*(sw gives you an extremely terse usage summary
370 and quits. You have to tell it to do
372 Most of the time you do this by giving \*(sw a
378 so that it knows what to do. There are some strange command line
379 options which cause \*(sw to do more exotic things, though.
381 .\"--------------------------------------------------------------------------
383 .SH "IMPLEMENTATION ODDITIES"
385 The \*(sw program that users use is really a small architecture-neutral
386 shell script, which works out the current architecture and executes the
387 appropriate architecture-specific main program. It's done this way so
388 that \*(sw knows that it can use the shell script to start itself up on
389 a remote host with a different architecture, something which it does
390 quite a lot. The only feature provided by the front-end shell script is
393 command line option, which shouldn't be used by anyone except \*(sw's build procedure anyway.
395 .\"--------------------------------------------------------------------------
397 .SH "COMMAND LINE OPTION REFERENCE"
399 Any \*(sw command line options can be put in the
401 environment variable. The \*(sw program will read space-separated
402 options from this variable before it reads the command line itself.
404 The \*(sw program usually understands two different names for each
405 option: a traditional Unix single-character name, and a long GNU-style
406 name. The short options behave in the normal Unix way: you can join
407 them together into single words with a
409 at the front, for example. The long names are always preceded by a
410 double dash. You can abbreviate long names as much as you like, as long
411 as the resulting abbreviation is unambiguous. In the descriptions
412 below, both the short and long names of the options are shown, but for
413 reasons of brevity required arguments are only shown for the long form.
415 There are conceptually two types of \*(sw command line options: those
416 which, usually for reasons of consistency with other programs, cause
417 \*(sw to do something immediately; and those which store some settings
418 for particular commands. The latter type are generally more useful.
419 It's worth bearing in mind, though, that the options are only used by a
420 few commands. The command reference describes exactly which commands
423 The complete list of command line options understood by the current
424 version of \*(sw is as follows:
427 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.
429 .B "\-H, \-\-help\-full"
430 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
431 text generated by this option. I recommend you pipe it through a pager
432 so that you can actually read it.
434 .B "\-v, \-\-version"
435 Writes \*(sw's version number to standard output and exits successfully. This is handy
436 when trying to decide whether your version of \*(sw has a particular feature, for example.
439 Writes a usage message so terse as to be nearly useless to standard
440 output and exits successfully. This is different from just running
442 because although both print the same useless message, running \*(sw without any arguments is considered an error, so the message is sent to
443 standard error and \*(sw will exit unsuccessfully.
445 .BI "\-a, \-\-arch " arch , arch\fR...
446 For commands which affect multiple architectures: only affect the
447 architectures specified. The architecture names may be separated by
448 commas, spaces or both, although clearly commas are most convenient on
449 the command line. Architecture names may be abbreviated as long as the
450 abbreviation is not ambiguous.
452 This option overrides any other decisions that \*(sw might make about which architectures to process based on the
454 list and the list of correctly built architectures for the current
458 For commands which affect multiple architectures: affect even
459 architectures that have been successfully built. This has no effect if
464 .B "\-i, \-\-install"
465 For build commands: this is the final install step, so label architectures
466 which successfully complete it as having been completely built. It's
467 normal to specify this option on the
468 .RB ` "make install" '
471 .BI "\-o, \-\-output " style
472 For build commands: select a style for the build output to be displayed
475 for more details on output styles.
478 For build commands: make a beep noise when the build finishes. This
479 provides a handy reminder if you're getting on with something else while
480 waiting for a long build. Use
484 to turn this option off. This option is disabled by default, although
485 may be enabled in the
487 environment variable.
489 .B "\-p, \-\-percent"
490 For build commands: enable translation of
492 sequences in command strings. These are described in more detail
494 .B "`%'-escape sequences"
499 to turn the option off. This option is enabled by default, although may
502 environment variable.
504 The remaining options aren't really intended for users. They're helpful
505 for \*(sw's own purposes, though, and described here for completeness' sake. They
506 don't have standard Unix short name equivalents, because they're not
507 usually useful for users.
510 Writes the \*(sw architecture name of the current host to standard output. This is used
511 by \*(sw's configuration script to determine the current architecture name. This
512 option is actually handled by a small shell script rather than by being
513 passed on to the main program. You shouldn't use this option yourself:
516 command instead. Because this option is handled by the shell script,
517 and the script isn't very clever, you can't abbreviate
519 on the command line, and it doesn't conflict with the similarly named
520 but completely different
522 option, which you can still abbreviate all the way down to just
526 Sets \*(sw's idea of its program name to
528 This is intended for use by \*(sw's front-end shell script, but isn't
529 actually needed at the moment. I can't see why you'd want to play with
530 this option, but it shouldn't do any harm.
532 .BI "\-\-remote " remote-command
533 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
534 using a bizarre binary packet protocol. If you really must know more
535 about this, see the source code: it's quite well documented, really.
537 .\"--------------------------------------------------------------------------
541 The descriptions below make use of some technical terms:
543 .B "architecture restriction"
544 A state created by the
546 command, restricting the
547 .I "default build architectures"
548 to those listed as arguments to the command. An architecture
549 restriction may be cleared by
553 .B "build architectures"
554 The architectures which a
558 option is specified on the command line, then its argument specifies the
559 build architectures for this command; otherwise, the
560 .I "default build architectures"
564 A command which executes a process on multiple hosts simultaneously and
565 reports the results. The processes executed usually perform some part
566 of the building of a package. Currently, the build commands are
573 .B "default build architectures"
574 The architectures which, in the absence of a
576 command line option, are affected by a
577 .IR "build command" .
578 To determine the default build architectures, \*(sw reads the list of all architectures from the
580 file, and filters it: if the
582 command line option is
584 specified, then architectures marked as
585 .I "successfully built"
586 are removed from the list; if there is an
587 .I "architecture restriction"
588 in force, then the list is further filtered according to the
591 .B "successfully built"
592 A package is considered to be successfully built on a given architecture
593 if a build command given the
595 command-line option succeeds on a host of that architecture. The list
596 of successfully built architectures can be cleared by the
600 option causes \*(sw to ignore whether architectures have been successfully built when
602 .IR "default build architectures" .
604 .\"--------------------------------------------------------------------------
606 .SH "COMMAND REFERENCE"
608 This section describes all of the available \*(sw commands, in alphabetical order.
611 Clears an architecture restriction set by
613 Subsequent build commands will run across all known architectures not
614 yet successfully built, unless overridden by the
616 command-line option, or a later
621 Writes the name of the local host's architecture to standard output.
622 The architecture name is built into \*(sw at compile time.
624 Writes information from the
626 file to the installed packages index file
627 .IB prefix /sw-index\fR.
629 \*(sw performs some checks before committing information to the index
630 file. Firstly, all the expected architectures must be successfully
631 built. Secondly, the script
632 .IB prefix /share/sw-precommit\fR
633 is run, if it exists. This script must exit successfully if the commit
634 is to proceed. The script can be configured to enforce local policy
635 requirements on installed software.
639 script is passed a single argument, which is the package name to be
640 committed. Other useful information is passed in the environment:
643 The package name (again).
646 The package version number.
649 The package's maintainer.
652 The last date on which the package was modified.
655 The list of architectures on which the package has been built (separated
656 by spaces or commas).
659 The installation prefix with which \*(sw was configured.
661 The script should report any errors it finds to its standard error
664 .SS configure \fR[\fIconfigure-arg\fR...]
665 Equivalent to the command
667 .BI "run ../configure \-\-prefix=" prefix " " configure-arg\fR...
671 is the installation prefix with which \*(sw itself was configured. If you want to specify a different prefix, pass
676 It is expected that administrators will set up a file
677 .IB prefix /share/config.site
678 which sets up other Autoconf parameters once the prefix has been
679 chosen. See the Autoconf manual for more information.
682 Writes to standard output the name of a host with requested architecture
684 The hostname is read from the
689 Builds symbolic link trees. For each of the build architectures, a
690 directory with the architecture's name is created containing a symbolic
691 link corresponding to each file in the main source tree. Thus, a `make'
692 in the link tree will fetch the source files correctly, but place the
693 objects in the link tree rather than the main source tree, so that
694 object files from different architectures don't interfere with each
697 If the link trees already exist, then rerunning
699 will update the links. This might be useful if the links somehow become
702 To turn some of the links in the link trees into real files, use the
707 Writes a list of all known architecture names to standard output. The
708 list is obtained by reading the
712 .SS make \fR[\fImake-arg\fR...]
715 .BI "run make " make-arg\fR...
719 .SS only\-arch \fIarch arch\fR...
720 Imposes an architecture restriction. Until cancelled by a later
724 command, the default build architectures will be limited to the
725 architectures listed on the command line. Architecture names may be
726 abbreviated as long as the abbreviation is not ambiguous.
730 .I "successfully built"
731 status of all architectures.
733 .SS rsh \fIhost\fR|\fIarch \fR[\fIcommand \fR[\fIargument\fR...]]
736 on a remote host, passing it the list of
740 command is unlike the standard
742 program and its replacements:
748 are not subjected to further shell expansion on the remote host.
750 The command is run with the remote current directory the same as the
751 local current directory, rather than the remote user's home directory.
753 The command is passed an environment constructed from the local
754 environment, the default remote environment, and
756 files, as described in the section
757 .B "Remote environment"
760 The remote command is run with standard input attached to
762 there is no way of running an interactive remote command through
765 The host on which to run the remote command may be specified as one of:
766 a standard host name (or IP address), an architecture name (which may
768 be abbreviated) signifying a host of the appropriate architecture, or
771 signifying the current host. (This last option may not sound useful,
772 but it's handy for testing.)
774 .SS run \fIcommand \fR[\fIargument\fR...]
775 Runs a command on all build architectures.
777 For each build architecture
779 \*(sw finds a host with the appropriate architecture, by choosing either
780 the local host or reading the hostname from the
782 file. It then performs the following actions on that host:
784 Sets the current directory to be the subdirectory named
786 of the directory from which the command was issued. This directory is
787 created if it doesn't already exist.
789 Sets up an environment constructed from the environment prevailing when
790 the command was issued, the default environment set up by
792 (or whatever equivalent remote execution program was actually used), and
795 files, as described in the section
796 .B "Remote environment"
799 Executes the program named
804 The command name and arguments may be subject to
806 substitution, depending on whether the
810 sequences are described in the section
811 .B "`%'-escape sequences"
814 Output from the command is both appended to the file
820 command-line option. See the section
822 below for more details.
826 option was given on the command line, each architecture on which the
827 command succeeds (i.e., reports a zero exit code) is marked as
828 .IR "successfully built" ,
829 and further build commands will not affect it unless the
831 command line option is passed, until a
833 command is performed.
835 .SS setup \fIpackage version \fR[\fImaintainer\fR]
836 Sets up various pieces of information required by \*(sw. The
837 information here will be added into the main index file by a
839 command. The information is maintained in a file named
841 in the current directory.
845 should be the basic name of the package, with versioning information
851 .RB ` emacs\-19.34 '.
854 should be the version number of the package. The
856 should be the name of the person principally responsible for maintaining
857 the package's local installation. If this isn't specified, the calling
858 user's name is used as the maintainer.
862 command must be run before any build command.
864 .SS snaplink \fIfile \fR[\fIfile\fR...]
865 Creates architecture-specific versions of a file. Every
867 named on the command line is copied to
869 for every build architecture
871 overwriting any existing file or symbolic link of that name. If
873 contains leading directories then destination directories are created as
874 necessary for the output files. Note that the `snap' operation doesn't
875 actually need to follow creation of link trees.
877 .\"--------------------------------------------------------------------------
879 .SH "`%'-ESCAPE SUBSTITUTION"
883 option is enabled, build commands and arguments are subject to
885 substitution before being executed. Certain two-character sequences,
886 with the first character
888 are replaced with strings, as follows:
891 The architecture name of the host executing the command.
894 The hostname of the host executing the command.
897 The directory prefix with which \*(sw was installed.
900 The name of the package being built.
903 The version number of the package being built.
906 The name of the maintainer of the package being built.
915 sequences which aren't understood are left as they are.
917 .\"--------------------------------------------------------------------------
921 Output from a build command is presented in one of a number of named
922 .IR "output styles" .
925 is always defined: it simply prefixes each line of output with the
926 name of the architecture which generated the line, which isn't actually
927 particularly easy to read. Other output styles may have been configured
928 into \*(sw when it was compiled.
930 The set of output styles supported by \*(sw varies according to how it
931 was configured. In any particular \*(sw program, you might have some of
935 Simply prefixes each output line with the name of the architecture it
936 came from. This is quite hard to read, but it doesn't require any
937 special operating system support or clever terminal.
940 Splits the terminal into independently scrolling areas, one for each
941 architecture, with a status line for each. Waits for a keypress when
942 all architectures are finished building.
946 style is used when the selected style doesn't work (for example, you
947 don't have a sufficiently capable terminal for curses output).
949 Output style names can be abbreviated as long as the abbreviation is
950 unambiguous. You can find the list of available output styles by
951 executing the command
955 (which is a little counter-intuitive, I know).
957 The author has plans to implement an X-based output style, but hasn't
958 got around to it yet.
960 .\"--------------------------------------------------------------------------
962 .SH "REMOTE ENVIRONMENT"
964 The environment for a remote command (executed either through the
966 command, or a build command) is set up as follows:
968 The complete environment passed to \*(sw is used as a basis.
970 Any environment variables defined by the remote execution program
973 override corresponding variables in the basis environment.
977 variable is set to the name of the remote host's architecture.
979 Variable assignments are read from the global
980 .IB prefix /share/sw\-env
981 file. This makes some assignments which are useful everywhere, and will
982 then usually include the file
984 in the current directory.
988 files is documented separately in
991 .\"--------------------------------------------------------------------------
995 This section describes how non-vendor software works at EBI. Chances
996 are that other sites will work differently. This description is here as
997 an example setup for \*(sw.
999 All the non-vendor software gets put in one big shared filesystem, and
1000 is exported from our main fileserver. The filesystem is mounted on all
1003 Architecture-neutral files are then
1004 placed in the conventional subdirectories off
1007 .BR /sw/common/share,
1009 .BR /sw/common/info ).
1010 Architecture specific files are stored in subdirectories off
1011 .BR /sw/common/arch .
1012 For example, Linux binaries go in
1013 .BR /sw/common/arch/i386-linux/bin ,
1014 and Solaris libraries in
1015 .BR /sw/common/arch/sparc-solaris/lib .
1016 Additionally, each architecture-specific subtree has a symbolic link
1019 for each of the architecture-neutral subdirectories.
1021 There is a symbolic link on every client, from
1024 .BI /sw/common/arch/ arch\fR,
1027 is the architecture of that client. Thus, every client has two
1029 of the software repository: the `common' view where every host sees
1030 exactly the same mapping between filenames and files, and the `arch'
1031 view where every host sees the same mapping between filenames and
1032 programs which do the same job.
1034 And that's just about it.
1036 .\"--------------------------------------------------------------------------
1040 The following environment variables are of interest to \*(sw:
1043 Contains a space-separated list of default command-line options. These
1044 are read before, and overridden by, the actual arguments given on the
1048 The name of the command to use to run a `make'. This is resolved on the
1049 local host once, rather than one for each build host, which is probably
1050 a misfeature. To do something more clever, point
1052 at a shell script which then picks out the right architecture-specific
1054 program from the remote environment.
1057 The name of the remote-shell program to use. By default, something
1060 is chosen. I recommend using the excellent
1064 .\"--------------------------------------------------------------------------
1068 The following files are of interest to \*(sw:
1070 .IB prefix /sw\-index
1071 The main index file, containing the list of which packages have been
1072 installed for which architectures. See
1074 for file format details.
1076 .IB prefix /share/archtab
1077 The architecture-to-host mapping file. See
1079 for file format details.
1081 .IB prefix /share/sw\-env
1082 Contains global environment variable settings. See
1084 for file format details.
1086 .IB prefix /share/sw\-precommit
1087 Optional script used to approve commit requests. See the
1089 command above for calling details.
1091 for file format details.
1093 .IB package /.sw\-info
1094 Contains the persistent information about a particular package's build
1097 for file format details.
1099 .IB package /.sw\-env
1100 Contains package-specific environment variable settings. See
1102 for file format details.
1104 .IB package / arch /.build\-log
1105 Contains all the build output for a particular architecture. Usually
1106 not very interesting, but might be handy one day.
1108 .\"--------------------------------------------------------------------------
1112 There are no bugs in
1114 merely unexpected behaviour modes. Silly you for thinking otherwise.
1126 The \*(sw program, and this manual, are \*(mw productions, in association
1127 with the European Bioinformatics Institute. They were written by Mark
1128 Wooding <mdw@nsict.org>. Go and ask him if you have problems.
1130 .\"----- That's all, folks --------------------------------------------------
~mdw / sw-tools / blob