mdw@git.distorted.org.uk Git - sw-tools/blob - README

   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