| 1 | SW-TOOLS |
| 2 | ~~~~~~~~ |
| 3 | |
| 4 | Quick introduction |
| 5 | |
| 6 | A few tools for maintaining user-contributed software at a site. |
| 7 | There are currently two main bits: |
| 8 | |
| 9 | * A tool for building programs on multiple machines |
| 10 | simultaneously. This saves time and effort and makes proper |
| 11 | support for multiple architectures more realistic. |
| 12 | |
| 13 | * A CGI script for navigating the documentation provided in |
| 14 | the contributed software area. |
| 15 | |
| 16 | There are also some other bits which aren't as interesting. |
| 17 | |
| 18 | |
| 19 | Installation |
| 20 | |
| 21 | The software comes with a `configure' script which should be |
| 22 | able to work out how to set the software up. You need an ANSI C |
| 23 | compiler (GCC would be best, probably), a POSIX-ish system, and |
| 24 | Perl 5.003 or later. |
| 25 | |
| 26 | Since it's designed to work in a heterogeneous environment, |
| 27 | here's how I'd do an initial build. First, unpack the |
| 28 | distribution archive (the thing this file came in) on some |
| 29 | network filesystem which all your hosts can see. Then make a |
| 30 | directory for each architecture. Now, once for each |
| 31 | architecture, change into the directory you made for it, and run |
| 32 | |
| 33 | ../configure --prefix=PREFIX --exec-prefix=EXEC-PREFIX |
| 34 | |
| 35 | where PREFIX is where you want your installed software to end |
| 36 | up, and EXEC-PREFIX is where architecture-specific things should |
| 37 | go for this architecture. (They can be the same if you like; I |
| 38 | don't recommend this). Then run `make', and `make install'. |
| 39 | You should now be ready. |
| 40 | |
| 41 | |
| 42 | Configuration |
| 43 | |
| 44 | The next thing to do is tell `sw' which architectures you have |
| 45 | and which machines compilations should be done on. Edit |
| 46 | PREFIX/share/archtab in a text editor, and fill it in, one entry |
| 47 | per line, architecture space hostname. Architecture names are |
| 48 | displayed by the configuration script as it goes, and can be |
| 49 | discovered by typing `sw arch' on the appropriate host. |
| 50 | |
| 51 | The main `sw' program should just work now. Read the manual to |
| 52 | find out how it works. The rest of this document assumes you've |
| 53 | done that. |
| 54 | |
| 55 | You can set up site policy by editing a script |
| 56 | PREFIX/share/sw-precommit if you like: if this script returns |
| 57 | failure, a `commit' command will fail. We use it here to ensure |
| 58 | that a user has written a documentation file for the package. |
| 59 | |
| 60 | The CGI script needs a little more work. You need to tell the |
| 61 | web server where to find it (by default it's gone into |
| 62 | EXEC-PREFIX/cgi-bin). You also need to edit its configuration |
| 63 | file, which is in PREFIX/share/sw.conf. The most important |
| 64 | thing to do is to uncomment the line saying that you've edited |
| 65 | the file; otherwise the script will complain at your users. You |
| 66 | should also fill in a value for `domain'. |
| 67 | |
| 68 | Then just publish the URL for the CGI, and everyone will be |
| 69 | happy. |
| 70 | |
| 71 | The script is described in sw-cgi(1). |
| 72 | |
| 73 | |
| 74 | Other stuff |
| 75 | |
| 76 | All of this was written by Mark Wooding. It's available under |
| 77 | the GNU General Public License, which you have a copy of in the |
| 78 | file called `COPYING' included with the distribution. You don't |
| 79 | get a warranty, not of any kind. If it doesn't work, that's |
| 80 | your hard luck. (Send me a bug report and I might fix it, |
| 81 | though.) |
| 82 | |
| 83 | Cheers, |
| 84 | |
| 85 | Mark Wooding, <mdw@nsict.org> |
| 86 | |
| 87 | \f |
| 88 | Local variables: |
| 89 | mode: text |
| 90 | End: |
| 91 | |