X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=contrib%2FSTANDARDS;h=f344dc555bd2412617a69d2ff0a95f504289ae84;hb=a0a413499415738d23cc40baa44e9c404af54a94;hp=f5b9598c3dd459a9f7b927abd2afa4139e5a2616;hpb=edc8da40fb17de047e290ed6bd819e096e435dc9;p=sbcl.git diff --git a/contrib/STANDARDS b/contrib/STANDARDS index f5b9598..f344dc5 100644 --- a/contrib/STANDARDS +++ b/contrib/STANDARDS @@ -56,7 +56,7 @@ If the contrib package involves more than one file, you are encouraged to use ASDF to build it and load it. A version of asdf is bundled as an SBCL contrib, which knows to look in $SBCL_HOME/systems/ for asd files - your install target should create an appropriate symlink there -to the installed location of the system file. Look in bsd-sockets/Makefile +to the installed location of the system file. Look in sb-bsd-sockets/Makefile for an example of an asdf-using contrib $(INSTALL_DIR) will have been created by the system before your @@ -77,25 +77,21 @@ of the preceding. Document formats not available on typical well-endowed-with-free-stuff Unix systems are discouraged. DocBook is fine, as the SBCL manual is DocBook anyway ] -[ install.sh should copy the documentation somewhere that the user can -find it ] +[ make install should copy the documentation somewhere that the user +can find it ] * Lisp-level requirements -An sbcl contrib should not stamp on sbcl internals or redefine symbols -in CL, CL-USER. Sometimes this is the only way to do something, -though: individual cases will be considered on their merits. A -package that hacks undocumented(sic) interfaces may be accepted for -contrib, but it does not follow from that that the interface is now -published or will be preserved in future SBCL versions - contrib -authors are encouraged instead to submit patches to SBCL that provide -clean documented APIs which reasonably can be preserved. If in doubt, -seek consensus on the sbcl-devel list +An sbcl contrib should attempt to avoid stamping on sbcl internals or +redefining symbols in CL, CL-USER. Sometimes this is the only way to do +something, though: individual cases will be considered on their +merits. A package that hacks undocumented(sic) interfaces may be +accepted for contrib, but it does not follow from that that the +interface is now published or will be preserved in future SBCL +versions - contrib authors are encouraged instead to submit patches to +SBCL that provide clean documented APIs which reasonably can be +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 -be chosen in some way that has reasonable expectation of being unique. -[We could potentially keep a registry of contrib archive name => -package name(s)] - - +begin with "SB-". Ask the sbcl-devel list for a suitable name.