3 .\" $Id: sw.1,v 1.7 1999/07/30 18:44:33 mdw Exp $
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 .\"----- Revision history ---------------------------------------------------
31 .\" Revision 1.7 1999/07/30 18:44:33 mdw
32 .\" Improve cross-references and tidy up formatting.
34 .\" Revision 1.6 1999/07/30 08:18:23 mdw
35 .\" Sweep with ispell and fix some typos.
37 .\" Revision 1.5 1999/07/16 12:45:37 mdw
38 .\" Internal formatting improvements.
40 .\" Revision 1.4 1999/06/24 15:52:12 mdw
41 .\" Add documentation for the `sw-precommit' script.
43 .\" Revision 1.3 1999/06/18 18:58:25 mdw
46 .\" Revision 1.2 1999/06/04 13:56:09 mdw
47 .\" Changes, extensions, polishings, spelling fixes...
49 .\" Revision 1.1.1.1 1999/06/02 16:53:33 mdw
53 .\"----- Style hacking ------------------------------------------------------
55 .de VS \" Start a sort-of verbatim block
61 .de VE \" Stop a sort-of verbatim block
67 .de hP \" Start an indented paragraph with a bold right-aligned label
69 \fB\h'-\w'\\$1\ 'u'\\$1\ \fP\c
74 . ds mw \fR[\f(BImdw\fR]
76 .el .ds mw \fR[\fBmdw\fR]
81 .\"----- Main manual text ---------------------------------------------------
83 .TH sw 1 "25 May 1999" sw-tools
86 .\"--------------------------------------------------------------------------
90 sw \- tool for convenient software installation
92 .\"--------------------------------------------------------------------------
101 \fBsw \-\-remote \fIcommand
106 \fBsw \fR[\fB\-fbi\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] [\fB\-o \fIstyle\fR] \fBconfigure \fR[\fIconfigure-arg\fR...]
108 \fBsw \fR[\fB\-f\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] \fBlinktree
110 \fBsw \fR[\fB\-fbi\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] [\fB\-o \fIstyle\fR] \fBmake \fR[\fImake-arg\fR...]
111 \fBsw only\-arch \fIarch \fR[\fIarch\fR...]
113 \fBsw rsh \fIhost\fR|\fIarch \fR[\fIcommand \fR[\fIargument\fR...]]
114 \fBsw \fR[\fB\-fbi\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] [\fB\-o \fIstyle\fR] \fBrun \fIcommand \fR[\fIargument\fR...]
115 \fBsw setup \fIpackage version \fR[\fImaintainer\fR]
116 \fBsw \fR[\fB\-f\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] \fBsnaplink \fIfile \fR[\fIfile\fR...]
121 .\"--------------------------------------------------------------------------
125 The \*(sw tool attempts to take a lot of the work out of building and
126 installing source packages across multiple architectures. This section
127 will describe how to use \*(sw's features to best advantage in a number
128 of common situations.
130 To keep things concrete, I'll describe how things are done at the EBI,
131 although there's nothing EBI-specific about the \*(sw program itself.
132 For details about how we handle software at EBI, see the
136 By the way, this is quite a large manual. I recommend that you print a
137 copy onto paper and peruse it in a leisurely fashion, rather than
138 squinting at a monitor.
140 .\"--------------------------------------------------------------------------
142 .SH "SUMMARY OF BUILDING PACKAGES"
148 .BI "sw setup " "package version"
150 .IR "arch " [ arch ...]
161 .BI "sw setup " "package version"
163 .IR "arch " [ arch ...]
166 .IR "file " [ file ...]
167 .I [edit the appropriate files]
174 .\"--------------------------------------------------------------------------
176 .SH "8 STEPS TO INSTALLING A PACKAGE"
178 The following steps will guide you through your first (and maybe second)
179 package installations. In the description, I'll use
181 to refer to the package's name, and
183 to refer to its version number.
185 Not all the important features and options are described in this part of
186 the manual. View it more as a taster for the sorts of things \*(sw can
188 .SS "1. Download the source distribution"
189 Download the package's source distribution. This will normally be in an
190 archive called something like
191 .IB package - version .tar.gz\c
192 \&. At EBI, we put source archive files in
194 .SS "2. Unpack the source tree"
195 Unpack the source tree into the standard source directory. Each source
196 tree should have its own directory. Most well-packaged source
197 distributions unpack themselves into a neat directory, but less
198 fastidious programmers make archives which scatter files all over the
201 At EBI, we put the source trees in
203 so unpacking a well-formed source distribution looks like:
206 .BI "gzip \-dc ../tr/" package \- version ".tar.gz | tar xfv \-"
208 Ill-formed source distributions involve making the directory for the
209 package first, changing into it, and then unpacking into the current
213 .BI "mkdir " package \- version
214 .BI "cd " package \- version
215 .BI "gzip \-dc ../../tr/" package - version ".tar.gz | tar xfv \-"
217 When you've finished unpacking, make sure that your current directory is
218 the top level directory of the source tree you unpacked.
219 .SS "3. Tell \\*(sw what you're up to"
220 Now you need to tell \*(sw what you're working on. It will keep track of
221 this and other bits of information in a little file and refer to it
222 every now and then. It will also whinge at you and refuse to cooperate
223 if it can't find its little file, so it's as well to oblige.
225 To tell \*(sw to create this little file and initialize it with sensible
226 values, you just need to say
228 .BI "sw setup " "package version"
230 What could be easier?
231 .SS "4. Restrict the build to particular architectures"
232 Some packages don't work on all architectures, either because the author
233 wasn't sufficiently good at writing portable software, or because the
234 program's doing inherently nonportable things.
236 If that's the case, then you need to tell \*(sw to only build on the
237 architectures that really work. Do this with the
239 command. For example, if your package only works on Linux and Solaris,
242 sw only i386-linux sparc-solaris
244 You can get a list of the architecture names that \*(sw understands by
249 With a little bit of luck, these names ought to be self-explanatory.
251 If your package is properly portable and works everywhere then you don't
252 need to do anything for this step. Skip on to the next one.
253 .SS "5. Configure the package"
254 Now it gets complicated. If the package you're building uses
256 to configure itself for its current environment then you're in luck.
259 package because there's a script called
261 in the top source directory, and a file called
271 to configure the package on all the platforms it's meant to be built
272 for. When you've done that, move onto the next step.
278 then all is not lost (although it may be worthwhile complaining at the
279 package's author or maintainers). You need to make a collection of
281 one for each architecture. These link trees are little replicas of the
282 main source tree but with symbolic links instead of the real source
283 files. To make the link trees, run
287 Now, that's not actually quite what you wanted. It's made a link for
289 file in the source tree. Unfortunately, there are some files you'll
290 (probably) have to modify for each architecture in order to configure
291 the package to build properly. You can turn links in the link trees
292 into real independently editable files by
294 the links. Say for example that
298 need to be modified for each architecture. Running the command
300 sw snaplink Makefile config.h
302 is sufficient to do the right thing.
304 Now you must edit the snapped files to configure the package. Make sure
305 that the install directories are correctly set. At EBI, all the
306 software should be configured so that architecture neutral files end up
309 and architecture-specific files end up under
310 .BI /sw/common/arch/ arch\c
312 .SS "6. Build the package"
313 Now you've laid the groundwork, everything ought to be easy. Making the
314 program ought to involve simply typing
318 and waiting for a while. If you had the
320 library available when \*(sw was built, then your terminal will split
321 itself into little independently scrolling windows showing you the
322 progress for each architecture. If you're not privileged enough to have
324 then you get the output appropriately tagged with architecture names,
325 which is unfortunately fairly hard to read.
326 .SS "7. Install the package"
327 Most source packages (and almost certainly all
333 which installs the program correctly. You can run this from \*(sw by
340 option there tells \*(sw that this is the
342 When an architecture completes this step correctly, it's marked as being
343 properly installed, and \*(sw doesn't bother thinking about it again.
349 makefile target, then you have to install things manually. That's not
350 much fun, so moan at the package's author. When you've finished
351 fiddling with installation, run
355 just to tell \*(sw that you've installed everything OK. (This is a bit
357 .SS "8. Update the index"
358 Now that everything's built and installed, there's just one more command
363 This makes \*(sw update its main index of installed packages, telling it
364 which architectures packages are installed on, and who did it.
366 .\"--------------------------------------------------------------------------
368 .SH "REFERENCE INTRODUCTION"
370 That was a gentle introduction. This section contains the complete
373 far more detail that you probably want. If that's really the case, try
378 to read the available help text. There's quite a lot of it, and it
379 ought to keep you occupied for a while.
381 The basic \*(sw command line looks a bit like:
394 at the shell prompt, \*(sw gives you an extremely terse usage summary
395 and quits. You have to tell it to do
397 Most of the time you do this by giving \*(sw a
403 so that it knows what to do. There are some strange command line
404 options which cause \*(sw to do more exotic things, though.
406 .\"--------------------------------------------------------------------------
408 .SH "IMPLEMENTATION ODDITIES"
410 The \*(sw program that users use is really a small architecture-neutral
411 shell script, which works out the current architecture and executes the
412 appropriate architecture-specific main program. It's done this way so
413 that \*(sw knows that it can use the shell script to start itself up on
414 a remote host with a different architecture, something which it does
415 quite a lot. The only feature provided by the front-end shell script is
418 command line option, which shouldn't be used by anyone except \*(sw's build procedure anyway.
420 .\"--------------------------------------------------------------------------
422 .SH "COMMAND LINE OPTION REFERENCE"
424 Any \*(sw command line options can be put in the
426 environment variable. The \*(sw program will read space-separated
427 options from this variable before it reads the command line itself.
429 The \*(sw program usually understands two different names for each
430 option: a traditional Unix single-character name, and a long GNU-style
431 name. The short options behave in the normal Unix way: you can join
432 them together into single words with a
434 at the front, for example. The long names are always preceded by a
435 double dash. You can abbreviate long names as much as you like, as long
436 as the resulting abbreviation is unambiguous. In the descriptions
437 below, both the short and long names of the options are shown, but for
438 reasons of brevity required arguments are only shown for the long form.
440 There are conceptually two types of \*(sw command line options: those
441 which, usually for reasons of consistency with other programs, cause
442 \*(sw to do something immediately; and those which store some settings
443 for particular commands. The latter type are generally more useful.
444 It's worth bearing in mind, though, that the options are only used by a
445 few commands. The command reference describes exactly which commands
448 The complete list of command line options understood by the current
449 version of \*(sw is as follows:
452 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.
454 .B "\-H, \-\-help\-full"
455 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
456 text generated by this option. I recommend you pipe it through a pager
457 so that you can actually read it.
459 .B "\-v, \-\-version"
460 Writes \*(sw's version number to standard output and exits successfully. This is handy
461 when trying to decide whether your version of \*(sw has a particular feature, for example.
464 Writes a usage message so terse as to be nearly useless to standard
465 output and exits successfully. This is different from just running
467 because although both print the same useless message, running \*(sw without any arguments is considered an error, so the message is sent to
468 standard error and \*(sw will exit unsuccessfully.
470 .BI "\-a, \-\-arch " arch , arch\fR...
471 For commands which affect multiple architectures: only affect the
472 architectures specified. The architecture names may be separated by
473 commas, spaces or both, although clearly commas are most convenient on
474 the command line. Architecture names may be abbreviated as long as the
475 abbreviation is not ambiguous.
477 This option overrides any other decisions that \*(sw might make about which architectures to process based on the
479 list and the list of correctly built architectures for the current
483 For commands which affect multiple architectures: affect even
484 architectures that have been successfully built. This has no effect if
489 .B "\-i, \-\-install"
490 For build commands: this is the final install step, so label architectures
491 which successfully complete it as having been completely built. It's
492 normal to specify this option on the
493 .RB ` "make install" '
496 .BI "\-o, \-\-output " style
497 For build commands: select a style for the build output to be displayed
500 for more details on output styles.
503 For build commands: make a beep noise when the build finishes. This
504 provides a handy reminder if you're getting on with something else while
505 waiting for a long build.
507 The remaining options aren't really intended for users. They're helpful
508 for \*(sw's own purposes, though, and described here for completeness' sake. They
509 don't have standard Unix short name equivalents, because they're not
510 usually useful for users.
513 Writes the \*(sw architecture name of the current host to standard output. This is used
514 by \*(sw's configuration script to determine the current architecture name. This
515 option is actually handled by a small shell script rather than by being
516 passed on to the main program. You shouldn't use this option yourself:
519 command instead. Because this option is handled by the shell script,
520 and the script isn't very clever, you can't abbreviate
522 on the command line, and it doesn't conflict with the similarly named
523 but completely different
525 option, which you can still abbreviate all the way down to just
529 Sets \*(sw's idea of its program name to
531 This is intended for use by \*(sw's front-end shell script, but isn't
532 actually needed at the moment. I can't see why you'd want to play with
533 this option, but it shouldn't do any harm.
535 .BI "\-\-remote " remote-command
536 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
537 using a bizarre binary packet protocol. If you really must know more
538 about this, see the source code: it's quite well documented, really.
540 .\"--------------------------------------------------------------------------
544 The descriptions below make use of some technical terms:
546 .B "architecture restriction"
547 A state created by the
549 command, restricting the
550 .I "default build architectures"
551 to those listed as arguments to the command. An architecture
552 restriction may be cleared by
556 .B "build architectures"
557 The architectures which a
561 option is specified on the command line, then its argument specifies the
562 build architectures for this command; otherwise, the
563 .I "default build architectures"
567 A command which executes a process on multiple hosts simultaneously and
568 reports the results. The processes executed usually perform some part
569 of the building of a package. Currently, the build commands are
576 .B "default build architectures"
577 The architectures which, in the absence of a
579 command line option, are affected by a
580 .IR "build command" .
581 To determine the default build architectures, \*(sw reads the list of all architectures from the
583 file, and filters it: if the
585 command line option is
587 specified, then architectures marked as
588 .I "successfully built"
589 are removed from the list; if there is an
590 .I "architecture restriction"
591 in force, then the list is further filtered according to the
594 .B "successfully built"
595 A package is considered to be successfully built on a given architecture
596 if a build command given the
598 command-line option succeeds on a host of that architecture. The list
599 of successfully built architectures can be cleared by the
603 option causes \*(sw to ignore whether architectures have been successfully built when
605 .IR "default build architectures" .
607 .\"--------------------------------------------------------------------------
609 .SH "COMMAND REFERENCE"
611 This section describes all of the available \*(sw commands, in alphabetical order.
614 Clears an architecture restriction set by
616 Subsequent build commands will run across all known architectures not
617 yet successfully built, unless overridden by the
619 command-line option, or a later
624 Writes the name of the local host's architecture to standard output.
625 The architecture name is built into \*(sw at compile time.
627 Writes information from the
629 file to the installed packages index file
630 .IB prefix /sw-index\fR.
632 \*(sw performs some checks before committing information to the index
633 file. Firstly, all the expected architectures must be successfully
634 built. Secondly, the script
635 .IB prefix /share/sw-precommit\fR
636 is run, if it exists. This script must exit successfully if the commit
637 is to proceed. The script can be configured to enforce local policy
638 requirements on installed software.
642 script is passed a single argument, which is the package name to be
643 committed. Other useful information is passed in the environment:
646 The package name (again).
649 The package version number.
652 The package's maintainer.
655 The last date on which the package was modified.
658 The list of architectures on which the package has been built (separated
659 by spaces or commas).
662 The installation prefix with which \*(sw was configured.
664 The script should report any errors it finds to its standard error
667 .SS configure \fR[\fIconfigure-arg\fR...]
668 Equivalent to the command
670 .BI "run ../configure \-\-prefix=" prefix " " configure-arg\fR...
674 is the installation prefix with which \*(sw itself was configured. If you want to specify a different prefix, pass
679 It is expected that administrators will set up a file
680 .IB prefix /share/config.site
681 which sets up other Autoconf parameters once the prefix has been
682 chosen. See the Autoconf manual for more information.
685 Writes to standard output the name of a host with requested architecture
687 The hostname is read from the
692 Builds symbolic link trees. For each of the build architectures, a
693 directory with the architecture's name is created containing a symbolic
694 link corresponding to each file in the main source tree. Thus, a `make'
695 in the link tree will fetch the source files correctly, but place the
696 objects in the link tree rather than the main source tree, so that
697 object files from different architectures don't interfere with each
700 If the link trees already exist, then rerunning
702 will update the links. This might be useful if the links somehow become
705 To turn some of the links in the link trees into real files, use the
710 Writes a list of all known architecture names to standard output. The
711 list is obtained by reading the
715 .SS make \fR[\fImake-arg\fR...]
718 .BI "run make " make-arg\fR...
722 .SS only\-arch \fIarch arch\fR...
723 Imposes an architecture restriction. Until cancelled by a later
727 command, the default build architectures will be limited to the
728 architectures listed on the command line. Architecture names may be
729 abbreviated as long as the abbreviation is not ambiguous.
733 .I "successfully built"
734 status of all architectures.
736 .SS rsh \fIhost\fR|\fIarch \fR[\fIcommand \fR[\fIargument\fR...]]
739 on a remote host, passing it the list of
743 command is unlike the standard
745 program and its replacements:
751 are not subjected to further shell expansion on the remote host.
753 The command is run with the remote current directory the same as the
754 local current directory, rather than the remote user's home directory.
756 The command is passed an environment constructed from the local
757 environment, the default remote environment, and
759 files, as described in the section
760 .B "Remote environment"
763 The remote command is run with standard input attached to
765 there is no way of running an interactive remote command through
768 The host on which to run the remote command may be specified as one of:
769 a standard host name (or IP address), an architecture name (which may
771 be abbreviated) signifying a host of the appropriate architecture, or
774 signifying the current host. (This last option may not sound useful,
775 but it's handy for testing.)
777 .SS run \fIcommand \fR[\fIargument\fR...]
778 Runs a command on all build architectures.
780 For each build architecture
782 \*(sw finds a host with the appropriate architecture, by choosing either
783 the local host or reading the hostname from the
785 file. It then performs the following actions on that host:
787 Sets the current directory to be the subdirectory named
789 of the directory from which the command was issued. This directory is
790 created if it doesn't already exist.
792 Sets up an environment constructed from the environment prevailing when
793 the command was issued, the default environment set up by
795 (or whatever equivalent remote execution program was actually used), and
798 files, as described in the section
799 .B "Remote environment"
802 Executes the program named
807 Output from the command is both appended to the file
813 command-line option. See the section
815 below for more details.
819 option was given on the command line, each architecture on which the
820 command succeeds (i.e., reports a zero exit code) is marked as
821 .IR "successfully built" ,
822 and further build commands will not affect it unless the
824 command line option is passed, until a
826 command is performed.
828 .SS setup \fIpackage version \fR[\fImaintainer\fR]
829 Sets up various pieces of information required by \*(sw. The
830 information here will be added into the main index file by a
832 command. The information is maintained in a file named
834 in the current directory.
838 should be the basic name of the package, with versioning information
844 .RB ` emacs\-19.34 '.
847 should be the version number of the package. The
849 should be the name of the person principally responsible for maintaining
850 the package's local installation. If this isn't specified, the calling
851 user's name is used as the maintainer.
855 command must be run before any build command.
857 .SS snaplink \fIfile \fR[\fIfile\fR...]
858 Creates architecture-specific versions of a file. Every
860 named on the command line is copied to
862 for every build architecture
864 overwriting any existing file or symbolic link of that name. If
866 contains leading directories then destination directories are created as
867 necessary for the output files. Note that the `snap' operation doesn't
868 actually need to follow creation of link trees.
870 .\"--------------------------------------------------------------------------
874 Output from a build command is presented in one of a number of named
875 .IR "output styles" .
878 is always defined: it simply prefixes each line of output with the
879 name of the architecture which generated the line, which isn't actually
880 particularly easy to read. Other output styles may have been configured
881 into \*(sw when it was compiled.
883 The set of output styles supported by \*(sw varies according to how it
884 was configured. In any particular \*(sw program, you might have some of
888 Simply prefixes each output line with the name of the architecture it
889 came from. This is quite hard to read, but it doesn't require any
890 special operating system support or clever terminal.
893 Splits the terminal into independently scrolling areas, one for each
894 architecture, with a status line for each. Waits for a keypress when
895 all architectures are finished building.
899 style is used when the selected style doesn't work (for example, you
900 don't have a sufficiently capable terminal for curses output).
902 Output style names can be abbreviated as long as the abbreviation is
903 unambiguous. You can find the list of available output styles by
904 executing the command
908 (which is a little counter-intuitive, I know).
910 The author has plans to implement an X-based output style, but hasn't
911 got around to it yet.
913 .\"--------------------------------------------------------------------------
915 .SH "REMOTE ENVIRONMENT"
917 The environment for a remote command (executed either through the
919 command, or a build command) is set up as follows:
921 The complete environment passed to \*(sw is used as a basis.
923 Any environment variables defined by the remote execution program
926 override corresponding variables in the basis environment.
930 variable is set to the name of the remote host's architecture.
932 Variable assignments are read from the global
933 .IB prefix /share/sw\-env
934 file. This makes some assignments which are useful everywhere, and will
935 then usually include the file
937 in the current directory.
941 files is documented separately in
944 .\"--------------------------------------------------------------------------
948 This section describes how non-vendor software works at EBI. Chances
949 are that other sites will work differently. This description is here as
950 an example setup for \*(sw.
952 All the non-vendor software gets put in one big shared filesystem, and
953 is exported from our main fileserver. The filesystem is mounted on all
956 Architecture-neutral files are then
957 placed in the conventional subdirectories off
960 .BR /sw/common/share,
962 .BR /sw/common/info ).
963 Architecture specific files are stored in subdirectories off
964 .BR /sw/common/arch .
965 For example, Linux binaries go in
966 .BR /sw/common/arch/i386-linux/bin ,
967 and Solaris libraries in
968 .BR /sw/common/arch/sparc-solaris/lib .
969 Additionally, each architecture-specific subtree has a symbolic link
972 for each of the architecture-neutral subdirectories.
974 There is a symbolic link on every client, from
977 .BI /sw/common/arch/ arch\fR,
980 is the architecture of that client. Thus, every client has two
982 of the software repository: the `common' view where every host sees
983 exactly the same mapping between filenames and files, and the `arch'
984 view where every host sees the same mapping between filenames and
985 programs which do the same job.
987 And that's just about it.
989 .\"--------------------------------------------------------------------------
993 The following environment variables are of interest to \*(sw:
996 Contains a space-separated list of default command-line options. These
997 are read before, and overridden by, the actual arguments given on the
1001 The name of the command to use to run a `make'. This is resolved on the
1002 local host once, rather than one for each build host, which is probably
1003 a misfeature. To do something more clever, point
1005 at a shell script which then picks out the right architecture-specific
1007 program from the remote environment.
1010 The name of the remote-shell program to use. By default, something
1013 is chosen. I recommend using the excellent
1017 .\"--------------------------------------------------------------------------
1021 The following files are of interest to \*(sw:
1023 .IB prefix /sw\-index
1024 The main index file, containing the list of which packages have been
1025 installed for which architectures. See
1027 for file format details.
1029 .IB prefix /share/archtab
1030 The architecture-to-host mapping file. See
1032 for file format details.
1034 .IB prefix /share/sw\-env
1035 Contains global environment variable settings. See
1037 for file format details.
1039 .IB prefix /share/sw\-precommit
1040 Optional script used to approve commit requests. See the
1042 command above for calling details.
1044 for file format details.
1046 .IB package /.sw\-info
1047 Contains the persistent information about a particular package's build
1050 for file format details.
1052 .IB package /.sw\-env
1053 Contains package-specific environment variable settings. See
1055 for file format details.
1057 .IB package / arch /.build\-log
1058 Contains all the build output for a particular architecture. Usually
1059 not very interesting, but might be handy one day.
1061 .\"--------------------------------------------------------------------------
1065 There are no bugs in
1067 merely unexpected behaviour modes. Silly you for thinking otherwise.
1079 The \*(sw program, and this manual, are \*(mw productions, in association
1080 with the European Bioinformatics Institute. They were written by Mark
1081 Wooding <mdw@nsict.org>. Go and ask him if you have problems.
1083 .\"----- That's all, folks --------------------------------------------------
~mdw / sw-tools / blob