This directory is for extensions to SBCL. They aren't necessary for
core SBCL functionality, or else they'd be built into the main SBCL
binary automatically. And they're not portable Common Lisp, or they'd
-be put elsewhere (e.g. http://clocc.sourceforge.net/).
+be put elsewhere (see http://sbcl.sf.net/libs.php for pointers)
+
+There are two kinds of contrib module in this directory:
+
+ * Newer contrib modules conform to the contrib standard (see
+ STANDARDS) and are automatically built and installed along with
+ SBCL itself. Each of these is in its own subdirectory with a
+ Makefile, and can be loaded with REQUIRE
+
+ Many of them use ASDF, so you have to require that first: e.g.
+
+ * (require 'asdf)
+ * (require 'sb-bsd-sockets)
+
+ * Older standalone files are effectively unpackaged and may or may
+ not work with the current SBCL version.
Some good candidates for future extensions here are:
* bindings to existing foreign libraries (e.g. to a regexp library
like PCRE, or to a compression library like zlib, or to a graphics
library like Tk)
- * new libraries (e.g. a CORBA interface, or a port of the CMU CL
- POSIX functions, or a new higher-level POSIX functions)
+ * new libraries (e.g. a CORBA interface)
* low-level hooks into SBCL needed to interface it to some wrapper
system (e.g. to interface to a graphical debugger of some sort)
* a too-alpha-to-be-supported-yet tree shaker
interface of the Oracle RDBMS, or particularly large extensions, e.g.
big graphics frameworks, can also be associated with the SBCL project,
but instead of being included in this directory as part of the
-distribution, they will be made available on the SBCL project web
-site.
+distribution, they will be made available or linked to on the SBCL
+project web site.
Proposed contrib standard, version $Revision$
-The SBCL contrib mechanism is intended to provide a mechanism to
+The SBCL contrib mechanism provides a mechanism to
manage code which does not form part of SBCL itself, but which is
sufficiently closely associated with it that it would not be sensible
to run it as a completely separate project. For example, alternative
against a given version of SBCL will not be installed in that release.
Note that despite leaving you the contrib maintainer with the
-responsibility of maintenance, we don't _necessarily_ (although we
-quite possibly would) offer you CVS access to the SBCL tree. This is
-because we can't do that without letting you write to the rest of the
-tree as well (at least as far as I know, at sourceforge).
+responsibility of maintenance, it doesn't follow that we'd
+_necessarily_ offer you CVS access to the SBCL tree: each application
+is considered individually. We often do, though.
** Release cycle
preserved. If in doubt, seek consensus on the sbcl-devel list
A contrib must load into its own Lisp package(s) instead of polluting
-CL-USER or one of the system packages. The Lisp package name should
+CL-USER or one of the system packages. The Lisp package names should
begin with "SB-". Ask the sbcl-devel list for a suitable name.