3 .\" $Id: sw.1,v 1.9 1999/09/16 12:34:13 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.9 1999/09/16 12:34:13 mdw
34 .\" Revision 1.8 1999/09/10 15:27:40 mdw
35 .\" Include `%'-escape substitution.
37 .\" Revision 1.7 1999/07/30 18:44:33 mdw
38 .\" Improve cross-references and tidy up formatting.
40 .\" Revision 1.6 1999/07/30 08:18:23 mdw
41 .\" Sweep with ispell and fix some typos.
43 .\" Revision 1.5 1999/07/16 12:45:37 mdw
44 .\" Internal formatting improvements.
46 .\" Revision 1.4 1999/06/24 15:52:12 mdw
47 .\" Add documentation for the `sw-precommit' script.
49 .\" Revision 1.3 1999/06/18 18:58:25 mdw
52 .\" Revision 1.2 1999/06/04 13:56:09 mdw
53 .\" Changes, extensions, polishings, spelling fixes...
55 .\" Revision 1.1.1.1 1999/06/02 16:53:33 mdw
59 .\"----- Style hacking ------------------------------------------------------
61 .de VS \" Start a sort-of verbatim block
67 .de VE \" Stop a sort-of verbatim block
73 .de hP \" Start an indented paragraph with a bold right-aligned label
75 \fB\h'-\w'\\$1\ 'u'\\$1\ \fP\c
80 . ds mw \fR[\f(BImdw\fR]
82 .el .ds mw \fR[\fBmdw\fR]
87 .\"----- Main manual text ---------------------------------------------------
89 .TH sw 1 "25 May 1999" sw-tools
92 .\"--------------------------------------------------------------------------
96 sw \- tool for convenient software installation
98 .\"--------------------------------------------------------------------------
107 \fBsw \-\-remote \fIcommand
112 \fBsw \fR[\fB\-fbip\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] [\fB\-o \fIstyle\fR] \fBconfigure \fR[\fIconfigure-arg\fR...]
114 \fBsw \fR[\fB\-f\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] \fBlinktree
116 \fBsw \fR[\fB\-fbip\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] [\fB\-o \fIstyle\fR] \fBmake \fR[\fImake-arg\fR...]
117 \fBsw only\-arch \fIarch \fR[\fIarch\fR...]
119 \fBsw rsh \fIhost\fR|\fIarch \fR[\fIcommand \fR[\fIargument\fR...]]
120 \fBsw \fR[\fB\-fbip\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] [\fB\-o \fIstyle\fR] \fBrun \fIcommand \fR[\fIargument\fR...]
121 \fBsw setup \fIpackage version \fR[\fImaintainer\fR]
122 \fBsw \fR[\fB\-f\fR] [\fB\-a \fIarch\fB,\fIarch\fR...] \fBsnaplink \fIfile \fR[\fIfile\fR...]
127 .\"--------------------------------------------------------------------------
131 The \*(sw tool attempts to take a lot of the work out of building and
132 installing source packages across multiple architectures. This section
133 will describe how to use \*(sw's features to best advantage in a number
134 of common situations.
136 To keep things concrete, I'll describe how things are done at the EBI,
137 although there's nothing EBI-specific about the \*(sw program itself.
138 For details about how we handle software at EBI, see the
142 By the way, this is quite a large manual. I recommend that you print a
143 copy onto paper and peruse it in a leisurely fashion, rather than
144 squinting at a monitor.
146 .\"--------------------------------------------------------------------------
148 .SH "SUMMARY OF BUILDING PACKAGES"
154 .BI "sw setup " "package version"
156 .IR "arch " [ arch ...]
167 .BI "sw setup " "package version"
169 .IR "arch " [ arch ...]
172 .IR "file " [ file ...]
173 .I [edit the appropriate files]
180 .\"--------------------------------------------------------------------------
182 .SH "8 STEPS TO INSTALLING A PACKAGE"
184 The following steps will guide you through your first (and maybe second)
185 package installations. In the description, I'll use
187 to refer to the package's name, and
189 to refer to its version number.
191 Not all the important features and options are described in this part of
192 the manual. View it more as a taster for the sorts of things \*(sw can
194 .SS "1. Download the source distribution"
195 Download the package's source distribution. This will normally be in an
196 archive called something like
197 .IB package - version .tar.gz\c
198 \&. At EBI, we put source archive files in
200 .SS "2. Unpack the source tree"
201 Unpack the source tree into the standard source directory. Each source
202 tree should have its own directory. Most well-packaged source
203 distributions unpack themselves into a neat directory, but less
204 fastidious programmers make archives which scatter files all over the
207 At EBI, we put the source trees in
209 so unpacking a well-formed source distribution looks like:
212 .BI "gzip \-dc ../tr/" package \- version ".tar.gz | tar xfv \-"
214 Ill-formed source distributions involve making the directory for the
215 package first, changing into it, and then unpacking into the current
219 .BI "mkdir " package \- version
220 .BI "cd " package \- version
221 .BI "gzip \-dc ../../tr/" package - version ".tar.gz | tar xfv \-"
223 When you've finished unpacking, make sure that your current directory is
224 the top level directory of the source tree you unpacked.
225 .SS "3. Tell \\*(sw what you're up to"
226 Now you need to tell \*(sw what you're working on. It will keep track of
227 this and other bits of information in a little file and refer to it
228 every now and then. It will also whinge at you and refuse to cooperate
229 if it can't find its little file, so it's as well to oblige.
231 To tell \*(sw to create this little file and initialize it with sensible
232 values, you just need to say
234 .BI "sw setup " "package version"
236 What could be easier?
237 .SS "4. Restrict the build to particular architectures"
238 Some packages don't work on all architectures, either because the author
239 wasn't sufficiently good at writing portable software, or because the
240 program's doing inherently nonportable things.
242 If that's the case, then you need to tell \*(sw to only build on the
243 architectures that really work. Do this with the
245 command. For example, if your package only works on Linux and Solaris,
248 sw only i386-linux sparc-solaris
250 You can get a list of the architecture names that \*(sw understands by
255 With a little bit of luck, these names ought to be self-explanatory.
257 If your package is properly portable and works everywhere then you don't
258 need to do anything for this step. Skip on to the next one.
259 .SS "5. Configure the package"
260 Now it gets complicated. If the package you're building uses
262 to configure itself for its current environment then you're in luck.
265 package because there's a script called
267 in the top source directory, and a file called
277 to configure the package on all the platforms it's meant to be built
278 for. When you've done that, move onto the next step.
284 then all is not lost (although it may be worthwhile complaining at the
285 package's author or maintainers). You need to make a collection of
287 one for each architecture. These link trees are little replicas of the
288 main source tree but with symbolic links instead of the real source
289 files. To make the link trees, run
293 Now, that's not actually quite what you wanted. It's made a link for
295 file in the source tree. Unfortunately, there are some files you'll
296 (probably) have to modify for each architecture in order to configure
297 the package to build properly. You can turn links in the link trees
298 into real independently editable files by
300 the links. Say for example that
304 need to be modified for each architecture. Running the command
306 sw snaplink Makefile config.h
308 is sufficient to do the right thing.
310 Now you must edit the snapped files to configure the package. Make sure
311 that the install directories are correctly set. At EBI, all the
312 software should be configured so that architecture neutral files end up
315 and architecture-specific files end up under
316 .BI /sw/common/arch/ arch\c
318 .SS "6. Build the package"
319 Now you've laid the groundwork, everything ought to be easy. Making the
320 program ought to involve simply typing
324 and waiting for a while. If you had the
326 library available when \*(sw was built, then your terminal will split
327 itself into little independently scrolling windows showing you the
328 progress for each architecture. If you're not privileged enough to have
330 then you get the output appropriately tagged with architecture names,
331 which is unfortunately fairly hard to read.
332 .SS "7. Install the package"
333 Most source packages (and almost certainly all
339 which installs the program correctly. You can run this from \*(sw by
346 option there tells \*(sw that this is the
348 When an architecture completes this step correctly, it's marked as being
349 properly installed, and \*(sw doesn't bother thinking about it again.
355 makefile target, then you have to install things manually. That's not
356 much fun, so moan at the package's author. When you've finished
357 fiddling with installation, run
361 just to tell \*(sw that you've installed everything OK. (This is a bit
363 .SS "8. Update the index"
364 Now that everything's built and installed, there's just one more command
369 This makes \*(sw update its main index of installed packages, telling it
370 which architectures packages are installed on, and who did it.
372 .\"--------------------------------------------------------------------------
374 .SH "REFERENCE INTRODUCTION"
376 That was a gentle introduction. This section contains the complete
379 far more detail that you probably want. If that's really the case, try
384 to read the available help text. There's quite a lot of it, and it
385 ought to keep you occupied for a while.
387 The basic \*(sw command line looks a bit like:
400 at the shell prompt, \*(sw gives you an extremely terse usage summary
401 and quits. You have to tell it to do
403 Most of the time you do this by giving \*(sw a
409 so that it knows what to do. There are some strange command line
410 options which cause \*(sw to do more exotic things, though.
412 .\"--------------------------------------------------------------------------
414 .SH "IMPLEMENTATION ODDITIES"
416 The \*(sw program that users use is really a small architecture-neutral
417 shell script, which works out the current architecture and executes the
418 appropriate architecture-specific main program. It's done this way so
419 that \*(sw knows that it can use the shell script to start itself up on
420 a remote host with a different architecture, something which it does
421 quite a lot. The only feature provided by the front-end shell script is
424 command line option, which shouldn't be used by anyone except \*(sw's build procedure anyway.
426 .\"--------------------------------------------------------------------------
428 .SH "COMMAND LINE OPTION REFERENCE"
430 Any \*(sw command line options can be put in the
432 environment variable. The \*(sw program will read space-separated
433 options from this variable before it reads the command line itself.
435 The \*(sw program usually understands two different names for each
436 option: a traditional Unix single-character name, and a long GNU-style
437 name. The short options behave in the normal Unix way: you can join
438 them together into single words with a
440 at the front, for example. The long names are always preceded by a
441 double dash. You can abbreviate long names as much as you like, as long
442 as the resulting abbreviation is unambiguous. In the descriptions
443 below, both the short and long names of the options are shown, but for
444 reasons of brevity required arguments are only shown for the long form.
446 There are conceptually two types of \*(sw command line options: those
447 which, usually for reasons of consistency with other programs, cause
448 \*(sw to do something immediately; and those which store some settings
449 for particular commands. The latter type are generally more useful.
450 It's worth bearing in mind, though, that the options are only used by a
451 few commands. The command reference describes exactly which commands
454 The complete list of command line options understood by the current
455 version of \*(sw is as follows:
458 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.
460 .B "\-H, \-\-help\-full"
461 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
462 text generated by this option. I recommend you pipe it through a pager
463 so that you can actually read it.
465 .B "\-v, \-\-version"
466 Writes \*(sw's version number to standard output and exits successfully. This is handy
467 when trying to decide whether your version of \*(sw has a particular feature, for example.
470 Writes a usage message so terse as to be nearly useless to standard
471 output and exits successfully. This is different from just running
473 because although both print the same useless message, running \*(sw without any arguments is considered an error, so the message is sent to
474 standard error and \*(sw will exit unsuccessfully.
476 .BI "\-a, \-\-arch " arch , arch\fR...
477 For commands which affect multiple architectures: only affect the
478 architectures specified. The architecture names may be separated by
479 commas, spaces or both, although clearly commas are most convenient on
480 the command line. Architecture names may be abbreviated as long as the
481 abbreviation is not ambiguous.
483 This option overrides any other decisions that \*(sw might make about which architectures to process based on the
485 list and the list of correctly built architectures for the current
489 For commands which affect multiple architectures: affect even
490 architectures that have been successfully built. This has no effect if
495 .B "\-i, \-\-install"
496 For build commands: this is the final install step, so label architectures
497 which successfully complete it as having been completely built. It's
498 normal to specify this option on the
499 .RB ` "make install" '
502 .BI "\-o, \-\-output " style
503 For build commands: select a style for the build output to be displayed
506 for more details on output styles.
509 For build commands: make a beep noise when the build finishes. This
510 provides a handy reminder if you're getting on with something else while
511 waiting for a long build. Use
515 to turn this option off. This option is disabled by default, although
516 may be enabled in the
518 environment variable.
520 .B "\-p, \-\-percent"
521 For build commands: enable translation of
523 sequences in command strings. These are described in more detail
525 .B "`%'-escape sequences"
530 to turn the option off. This option is enabled by default, although may
533 environment variable.
535 The remaining options aren't really intended for users. They're helpful
536 for \*(sw's own purposes, though, and described here for completeness' sake. They
537 don't have standard Unix short name equivalents, because they're not
538 usually useful for users.
541 Writes the \*(sw architecture name of the current host to standard output. This is used
542 by \*(sw's configuration script to determine the current architecture name. This
543 option is actually handled by a small shell script rather than by being
544 passed on to the main program. You shouldn't use this option yourself:
547 command instead. Because this option is handled by the shell script,
548 and the script isn't very clever, you can't abbreviate
550 on the command line, and it doesn't conflict with the similarly named
551 but completely different
553 option, which you can still abbreviate all the way down to just
557 Sets \*(sw's idea of its program name to
559 This is intended for use by \*(sw's front-end shell script, but isn't
560 actually needed at the moment. I can't see why you'd want to play with
561 this option, but it shouldn't do any harm.
563 .BI "\-\-remote " remote-command
564 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
565 using a bizarre binary packet protocol. If you really must know more
566 about this, see the source code: it's quite well documented, really.
568 .\"--------------------------------------------------------------------------
572 The descriptions below make use of some technical terms:
574 .B "architecture restriction"
575 A state created by the
577 command, restricting the
578 .I "default build architectures"
579 to those listed as arguments to the command. An architecture
580 restriction may be cleared by
584 .B "build architectures"
585 The architectures which a
589 option is specified on the command line, then its argument specifies the
590 build architectures for this command; otherwise, the
591 .I "default build architectures"
595 A command which executes a process on multiple hosts simultaneously and
596 reports the results. The processes executed usually perform some part
597 of the building of a package. Currently, the build commands are
604 .B "default build architectures"
605 The architectures which, in the absence of a
607 command line option, are affected by a
608 .IR "build command" .
609 To determine the default build architectures, \*(sw reads the list of all architectures from the
611 file, and filters it: if the
613 command line option is
615 specified, then architectures marked as
616 .I "successfully built"
617 are removed from the list; if there is an
618 .I "architecture restriction"
619 in force, then the list is further filtered according to the
622 .B "successfully built"
623 A package is considered to be successfully built on a given architecture
624 if a build command given the
626 command-line option succeeds on a host of that architecture. The list
627 of successfully built architectures can be cleared by the
631 option causes \*(sw to ignore whether architectures have been successfully built when
633 .IR "default build architectures" .
635 .\"--------------------------------------------------------------------------
637 .SH "COMMAND REFERENCE"
639 This section describes all of the available \*(sw commands, in alphabetical order.
642 Clears an architecture restriction set by
644 Subsequent build commands will run across all known architectures not
645 yet successfully built, unless overridden by the
647 command-line option, or a later
652 Writes the name of the local host's architecture to standard output.
653 The architecture name is built into \*(sw at compile time.
655 Writes information from the
657 file to the installed packages index file
658 .IB prefix /sw-index\fR.
660 \*(sw performs some checks before committing information to the index
661 file. Firstly, all the expected architectures must be successfully
662 built. Secondly, the script
663 .IB prefix /share/sw-precommit\fR
664 is run, if it exists. This script must exit successfully if the commit
665 is to proceed. The script can be configured to enforce local policy
666 requirements on installed software.
670 script is passed a single argument, which is the package name to be
671 committed. Other useful information is passed in the environment:
674 The package name (again).
677 The package version number.
680 The package's maintainer.
683 The last date on which the package was modified.
686 The list of architectures on which the package has been built (separated
687 by spaces or commas).
690 The installation prefix with which \*(sw was configured.
692 The script should report any errors it finds to its standard error
695 .SS configure \fR[\fIconfigure-arg\fR...]
696 Equivalent to the command
698 .BI "run ../configure \-\-prefix=" prefix " " configure-arg\fR...
702 is the installation prefix with which \*(sw itself was configured. If you want to specify a different prefix, pass
707 It is expected that administrators will set up a file
708 .IB prefix /share/config.site
709 which sets up other Autoconf parameters once the prefix has been
710 chosen. See the Autoconf manual for more information.
713 Writes to standard output the name of a host with requested architecture
715 The hostname is read from the
720 Builds symbolic link trees. For each of the build architectures, a
721 directory with the architecture's name is created containing a symbolic
722 link corresponding to each file in the main source tree. Thus, a `make'
723 in the link tree will fetch the source files correctly, but place the
724 objects in the link tree rather than the main source tree, so that
725 object files from different architectures don't interfere with each
728 If the link trees already exist, then rerunning
730 will update the links. This might be useful if the links somehow become
733 To turn some of the links in the link trees into real files, use the
738 Writes a list of all known architecture names to standard output. The
739 list is obtained by reading the
743 .SS make \fR[\fImake-arg\fR...]
746 .BI "run make " make-arg\fR...
750 .SS only\-arch \fIarch arch\fR...
751 Imposes an architecture restriction. Until cancelled by a later
755 command, the default build architectures will be limited to the
756 architectures listed on the command line. Architecture names may be
757 abbreviated as long as the abbreviation is not ambiguous.
761 .I "successfully built"
762 status of all architectures.
764 .SS rsh \fIhost\fR|\fIarch \fR[\fIcommand \fR[\fIargument\fR...]]
767 on a remote host, passing it the list of
771 command is unlike the standard
773 program and its replacements:
779 are not subjected to further shell expansion on the remote host.
781 The command is run with the remote current directory the same as the
782 local current directory, rather than the remote user's home directory.
784 The command is passed an environment constructed from the local
785 environment, the default remote environment, and
787 files, as described in the section
788 .B "Remote environment"
791 The remote command is run with standard input attached to
793 there is no way of running an interactive remote command through
796 The host on which to run the remote command may be specified as one of:
797 a standard host name (or IP address), an architecture name (which may
799 be abbreviated) signifying a host of the appropriate architecture, or
802 signifying the current host. (This last option may not sound useful,
803 but it's handy for testing.)
805 .SS run \fIcommand \fR[\fIargument\fR...]
806 Runs a command on all build architectures.
808 For each build architecture
810 \*(sw finds a host with the appropriate architecture, by choosing either
811 the local host or reading the hostname from the
813 file. It then performs the following actions on that host:
815 Sets the current directory to be the subdirectory named
817 of the directory from which the command was issued. This directory is
818 created if it doesn't already exist.
820 Sets up an environment constructed from the environment prevailing when
821 the command was issued, the default environment set up by
823 (or whatever equivalent remote execution program was actually used), and
826 files, as described in the section
827 .B "Remote environment"
830 Executes the program named
835 The command name and arguments may be subject to
837 substitution, depending on whether the
841 sequences are described in the section
842 .B "`%'-escape sequences"
845 Output from the command is both appended to the file
851 command-line option. See the section
853 below for more details.
857 option was given on the command line, each architecture on which the
858 command succeeds (i.e., reports a zero exit code) is marked as
859 .IR "successfully built" ,
860 and further build commands will not affect it unless the
862 command line option is passed, until a
864 command is performed.
866 .SS setup \fIpackage version \fR[\fImaintainer\fR]
867 Sets up various pieces of information required by \*(sw. The
868 information here will be added into the main index file by a
870 command. The information is maintained in a file named
872 in the current directory.
876 should be the basic name of the package, with versioning information
882 .RB ` emacs\-19.34 '.
885 should be the version number of the package. The
887 should be the name of the person principally responsible for maintaining
888 the package's local installation. If this isn't specified, the calling
889 user's name is used as the maintainer.
893 command must be run before any build command.
895 .SS snaplink \fIfile \fR[\fIfile\fR...]
896 Creates architecture-specific versions of a file. Every
898 named on the command line is copied to
900 for every build architecture
902 overwriting any existing file or symbolic link of that name. If
904 contains leading directories then destination directories are created as
905 necessary for the output files. Note that the `snap' operation doesn't
906 actually need to follow creation of link trees.
908 .\"--------------------------------------------------------------------------
910 .SH "`%'-ESCAPE SUBSTITUTION"
914 option is enabled, build commands and arguments are subject to
916 substitution before being executed. Certain two-character sequences,
917 with the first character
919 are replaced with strings, as follows:
922 The architecture name of the host executing the command.
925 The hostname of the host executing the command.
928 The directory prefix with which \*(sw was installed.
931 The name of the package being built.
934 The version number of the package being built.
937 The name of the maintainer of the package being built.
946 sequences which aren't understood are left as they are.
948 .\"--------------------------------------------------------------------------
952 Output from a build command is presented in one of a number of named
953 .IR "output styles" .
956 is always defined: it simply prefixes each line of output with the
957 name of the architecture which generated the line, which isn't actually
958 particularly easy to read. Other output styles may have been configured
959 into \*(sw when it was compiled.
961 The set of output styles supported by \*(sw varies according to how it
962 was configured. In any particular \*(sw program, you might have some of
966 Simply prefixes each output line with the name of the architecture it
967 came from. This is quite hard to read, but it doesn't require any
968 special operating system support or clever terminal.
971 Splits the terminal into independently scrolling areas, one for each
972 architecture, with a status line for each. Waits for a keypress when
973 all architectures are finished building.
977 style is used when the selected style doesn't work (for example, you
978 don't have a sufficiently capable terminal for curses output).
980 Output style names can be abbreviated as long as the abbreviation is
981 unambiguous. You can find the list of available output styles by
982 executing the command
986 (which is a little counter-intuitive, I know).
988 The author has plans to implement an X-based output style, but hasn't
989 got around to it yet.
991 .\"--------------------------------------------------------------------------
993 .SH "REMOTE ENVIRONMENT"
995 The environment for a remote command (executed either through the
997 command, or a build command) is set up as follows:
999 The complete environment passed to \*(sw is used as a basis.
1001 Any environment variables defined by the remote execution program
1004 override corresponding variables in the basis environment.
1008 variable is set to the name of the remote host's architecture.
1010 Variable assignments are read from the global
1011 .IB prefix /share/sw\-env
1012 file. This makes some assignments which are useful everywhere, and will
1013 then usually include the file
1015 in the current directory.
1019 files is documented separately in
1022 .\"--------------------------------------------------------------------------
1026 This section describes how non-vendor software works at EBI. Chances
1027 are that other sites will work differently. This description is here as
1028 an example setup for \*(sw.
1030 All the non-vendor software gets put in one big shared filesystem, and
1031 is exported from our main fileserver. The filesystem is mounted on all
1034 Architecture-neutral files are then
1035 placed in the conventional subdirectories off
1038 .BR /sw/common/share,
1040 .BR /sw/common/info ).
1041 Architecture specific files are stored in subdirectories off
1042 .BR /sw/common/arch .
1043 For example, Linux binaries go in
1044 .BR /sw/common/arch/i386-linux/bin ,
1045 and Solaris libraries in
1046 .BR /sw/common/arch/sparc-solaris/lib .
1047 Additionally, each architecture-specific subtree has a symbolic link
1050 for each of the architecture-neutral subdirectories.
1052 There is a symbolic link on every client, from
1055 .BI /sw/common/arch/ arch\fR,
1058 is the architecture of that client. Thus, every client has two
1060 of the software repository: the `common' view where every host sees
1061 exactly the same mapping between filenames and files, and the `arch'
1062 view where every host sees the same mapping between filenames and
1063 programs which do the same job.
1065 And that's just about it.
1067 .\"--------------------------------------------------------------------------
1071 The following environment variables are of interest to \*(sw:
1074 Contains a space-separated list of default command-line options. These
1075 are read before, and overridden by, the actual arguments given on the
1079 The name of the command to use to run a `make'. This is resolved on the
1080 local host once, rather than one for each build host, which is probably
1081 a misfeature. To do something more clever, point
1083 at a shell script which then picks out the right architecture-specific
1085 program from the remote environment.
1088 The name of the remote-shell program to use. By default, something
1091 is chosen. I recommend using the excellent
1095 .\"--------------------------------------------------------------------------
1099 The following files are of interest to \*(sw:
1101 .IB prefix /sw\-index
1102 The main index file, containing the list of which packages have been
1103 installed for which architectures. See
1105 for file format details.
1107 .IB prefix /share/archtab
1108 The architecture-to-host mapping file. See
1110 for file format details.
1112 .IB prefix /share/sw\-env
1113 Contains global environment variable settings. See
1115 for file format details.
1117 .IB prefix /share/sw\-precommit
1118 Optional script used to approve commit requests. See the
1120 command above for calling details.
1122 for file format details.
1124 .IB package /.sw\-info
1125 Contains the persistent information about a particular package's build
1128 for file format details.
1130 .IB package /.sw\-env
1131 Contains package-specific environment variable settings. See
1133 for file format details.
1135 .IB package / arch /.build\-log
1136 Contains all the build output for a particular architecture. Usually
1137 not very interesting, but might be handy one day.
1139 .\"--------------------------------------------------------------------------
1143 There are no bugs in
1145 merely unexpected behaviour modes. Silly you for thinking otherwise.
1157 The \*(sw program, and this manual, are \*(mw productions, in association
1158 with the European Bioinformatics Institute. They were written by Mark
1159 Wooding <mdw@nsict.org>. Go and ask him if you have problems.
1161 .\"----- That's all, folks --------------------------------------------------
~mdw / sw-tools / blob