0.pre7.125:

[sbcl.git] / base-target-features.lisp-expr

diff --git a/base-target-features.lisp-expr b/base-target-features.lisp-expr
index a116e33..671f0fb 100644 (file)
--- a/base-target-features.lisp-expr
+++ b/base-target-features.lisp-expr
@@ -5,8 +5,10 @@
 ;;;;
 ;;;; Note that the recommended way to customize the features of a
 ;;;; local build of SBCL is not to edit this file, but instead to
-;;;; tweak customize-target-features.lisp. E.g. you can use code like
-;;;; this:
+;;;; tweak customize-target-features.lisp. If you define a function
+;;;; in customize-target-features.lisp, it will be used to transform
+;;;; the target features list after it's read and before it's used.
+;;;; E.g. you can use code like this:
 ;;;;    (lambda (list)
 ;;;;      (flet ((enable (x) (pushnew x list))
 ;;;;            (disable (x) (setf list (remove x list))))
@@ -14,9 +16,12 @@
 ;;;;        (enable :sb-after-xc-core)
 ;;;;        #+nil (disable :sb-doc)
 ;;;;        list))
-;;;; That way, because customize-target-features.lisp is in
-;;;; .cvsignore, your local changes will remain local even if you use
-;;;; "cvs diff" to submit patches to SBCL.
+;;;; By thus editing a local file (one which is not in the source
+;;;; distribution, and which is in .cvsignore) your customizations
+;;;; will remain local even if you do things like "cvs update",
+;;;; will not show up if you try to submit a patch with "cvs diff",
+;;;; and might even stay out of the way if you use other non-CVS-based
+;;;; methods to upgrade the files or store your configuration.
 
 ;;;; This software is part of the SBCL system. See the README file for
 ;;;; more information.
@@ -97,14 +102,15 @@
 
  ;; Build SBCL with the old CMU CL low level debugger, "ldb". If 
  ;; are aren't messing with CMU CL at a very low level (e.g. 
- ;; trying to diagnose GC problems) you shouldn't need this.
+ ;; trying to diagnose GC problems, or trying to debug assembly
+ ;; code for a port to a new CPU) you shouldn't need this.
  ; :sb-ldb
 
  ;; This isn't really a target Lisp feature at all, but controls
  ;; whether the build process produces an after-xc.core file. This
- ;; can be useful for shortening the edit/compile/debug cycle if
- ;; you're messing around with low-level internals of the system,
- ;; as in slam.sh. Otherwise you don't need it.
+ ;; can be useful for shortening the edit/compile/debug cycle when
+ ;; you modify SBCL's own source code, as in slam.sh. Otherwise
+ ;; you don't need it.
  ; :sb-after-xc-core
 
  ;; Enable extra debugging output in the assem.lisp assembler/scheduler
@@ -128,10 +134,13 @@
  ;; anyone who wants to collect such statistics in the future.
  ; :sb-dyncount
 
- ;; Peter Van Eynde's increase-bulletproofness code
+ ;; Peter Van Eynde's increase-bulletproofness code for CMU CL
  ;;
- ;; This is not maintained or tested in current SBCL, but I haven't
- ;; gone out of my way to remove or break it, either.
+ ;; Some of the code which was #+high-security before the fork has now
+ ;; been either made unconditional, deleted, or rewritten into
+ ;; unrecognizability, but some remains. What remains is not maintained
+ ;; or tested in current SBCL, but I haven't gone out of my way to
+ ;; break it, either. 
  ;;
  ; :high-security
  ; :high-security-support
@@ -169,10 +178,6 @@
  ;; the underlying x86 hardware tries).
  :ieee-floating-point
 
- ;; This seems to be the pre-GENCGC garbage collector for CMU CL, which was
- ;; AFAIK never supported for the X86.
- ; :gengc
-
  ;; CMU CL had, and we inherited, code to support 80-bit LONG-FLOAT on the x86
  ;; architecture. Nothing has been done to actively destroy the long float
  ;; support, but it hasn't been thoroughly maintained, and needs at least