Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
tag: sbcl_0_9_6
Fetching contributors…

Octocat-spinner-32-eaf2f5

Cannot retrieve contributors at this time

file 297 lines (267 sloc) 13.575 kb
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296
;;;; -*- Lisp -*-

;;;; tags which are set during the build process and which end up in
;;;; CL:*FEATURES* in the target SBCL, plus some comments about other
;;;; CL:*FEATURES* tags which have special meaning to SBCL or which
;;;; have a special conventional meaning
;;;;
;;;; 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. 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))))
;;;; #+nil (enable :sb-show)
;;;; (enable :sb-after-xc-core)
;;;; #+nil (disable :sb-doc)
;;;; list))
;;;; 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.
;;;;
;;;; This software is derived from the CMU CL system, which was
;;;; written at Carnegie Mellon University and released into the
;;;; public domain. The software is in the public domain and is
;;;; provided with absolutely no warranty. See the COPYING and CREDITS
;;;; files for more information.

(
 ;;
 ;; features present in all builds
 ;;

 ;; our standard
 :ansi-cl :common-lisp
 ;; FIXME: Isn't there a :x3jsomething feature which we should set too?
 ;; No. CLHS says ":x3j13 [...] A conforming implementation might or
 ;; might not contain such a feature." -- CSR, 2002-02-21

 ;; our dialect
 :sbcl

 ;; Douglas Thomas Crosher's conservative generational GC (the only one
 ;; we currently support for X86).
 ;; :gencgc used to be here; CSR moved it into
 ;; local-target-features.lisp-expr via make-config.sh, as alpha,
 ;; sparc and ppc ports don't currently support it. -- CSR, 2002-02-21

 ;; We're running under a UNIX. This is sort of redundant, and it was also
 ;; sort of redundant under CMU CL, which we inherited it from: neither SBCL
 ;; nor CMU CL supports anything but UNIX (and "technically not UNIX"es
 ;; such as *BSD and Linux). But someday, maybe we might, and in that case
 ;; we'd presumably remove this, so its presence conveys the information
 ;; that the system isn't one which follows such a change.
 :unix

 ;;
 ;; features present in this particular build
 ;;

 ;; Setting this enables the compilation of documentation strings
 ;; from the system sources into the target Lisp executable.
 ;; Traditional Common Lisp folk will want this option set.
 ;; I (WHN) made it optional because I came to Common Lisp from
 ;; C++ through Scheme, so I'm accustomed to asking
 ;; Emacs about things that I'm curious about instead of asking
 ;; the executable I'm running.
 :sb-doc

 ;; Do regression and other tests when building the system. You might
 ;; or might not want this if you're not a developer, depending on how
 ;; paranoid you are. You probably do want it if you are a developer.
 ;; This test does not affect the target system (in much the same way
 ;; as :sb-after-xc-core, below).
 :sb-test

 ;; Make more debugging information available (for debugging SBCL
 ;; itself). If you aren't hacking or troubleshooting SBCL itself,
 ;; you probably don't want this set.
 ;;
 ;; At least two varieties of debugging information are enabled by this
 ;; option:
 ;; * SBCL is compiled with a higher level of OPTIMIZE DEBUG, so that
 ;; the debugger can tell more about the state of the system.
 ;; * Various code to print debugging messages, and similar debugging code,
 ;; is compiled only when this feature is present.
 ;;
 ;; Note that the extra information recorded by the compiler at
 ;; this higher level of OPTIMIZE DEBUG includes the source location
 ;; forms. In order for the debugger to use this information, it has to
 ;; re-READ the source file. In an ordinary installation of SBCL, this
 ;; re-READing may not work very well, for either of two reasons:
 ;; * The sources aren't present on the system in the same location that
 ;; they were on the system where SBCL was compiled.
 ;; * SBCL is using the standard readtable, without the added hackage
 ;; which allows it to handle things like target features.
 ;; If you want to be able to use the extra debugging information,
 ;; therefore, be sure to keep the sources around, and run with the
 ;; readtable configured so that the system sources can be read.
 ; :sb-show

 ;; Build SBCL with the old CMU CL low level debugger, "ldb". If are
 ;; aren't messing with SBCL at a very low level (e.g., 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 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
 ;; code. (This is the feature which was called :DEBUG in the
 ;; original CMU CL code.)
 ; :sb-show-assem

 ;; Setting this makes SBCL more "fluid", i.e. more amenable to
 ;; modification at runtime, by suppressing various INLINE declarations,
 ;; compiler macro definitions, FREEZE-TYPE declarations; and by
 ;; suppressing various burning-our-ships-behind-us actions after
 ;; initialization is complete; and so forth. This tends to clobber the
 ;; performance of the system, so unless you have some special need for
 ;; this when hacking SBCL itself, you don't want this set.
 ; :sb-fluid

 ;; Enable code for collecting statistics on usage of various operations,
 ;; useful for performance tuning of the SBCL system itself. This code
 ;; is probably pretty stale (having not been tested since the fork from
 ;; base CMU CL) but might nonetheless be a useful starting point for
 ;; anyone who wants to collect such statistics in the future.
 ; :sb-dyncount

 ;; Peter Van Eynde's increase-bulletproofness code for CMU CL
 ;;
 ;; 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

 ;; low-level thread primitives support
 ;;
 ;; As of SBCL 0.8, this is only supposed to work in x86 Linux with
 ;; NPTL support (usually kernel 2.6, though sme Red Hat distributions
 ;; with older kernels also have it) and is implemented using clone(2)
 ;; and the %fs segment register. Note that no consistent effort to
 ;; audit the SBCL library code for thread safety has been performed,
 ;; so caveat executor.
 ; :sb-thread

 ;; Support for detection of unportable code (when applied to the
 ;; COMMON-LISP package, or SBCL-internal pacakges) or bad-neighbourly
 ;; code (when applied to user-level packages), relating to material
 ;; alteration to packages or to bindings in symbols in packages.
 :sb-package-locks

 ;; Support for the entirety of the 21-bit character space defined by
 ;; the Unicode consortium, rather than the classical 8-bit ISO-8859-1
 ;; character set.
 :sb-unicode

 ;; This affects the definition of a lot of things in bignum.lisp. It
 ;; doesn't seem to be documented anywhere what systems it might apply
 ;; to. It doesn't seem to be needed for X86 systems anyway.
 ; :32x16-divide

 ;; This is set in classic CMU CL, and presumably there it means
 ;; that the floating point arithmetic implementation
 ;; conforms to IEEE's standard. Here it definitely means that the
 ;; floating point arithmetic implementation conforms to IEEE's standard.
 ;; I (WHN 19990702) haven't tried to verify
 ;; that it does conform, but it should at least mostly conform (because
 ;; the underlying x86 hardware tries).
 :ieee-floating-point

 ;; 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
 ;; some maintenance before it will work. (E.g. the LONG-FLOAT-only parts of
 ;; genesis are still implemented in terms of unportable CMU CL functions
 ;; which are not longer available at genesis time in SBCL.) A deeper
 ;; problem is SBCL's bootstrap process implicitly assumes that the
 ;; cross-compilation host will be able to make the same distinctions
 ;; between floating point types that it does. This assumption is
 ;; fundamentally sleazy, even though in practice it's unlikely to break down
 ;; w.r.t. distinguishing SINGLE-FLOAT from DOUBLE-FLOAT; it's much more
 ;; likely to break down w.r.t. distinguishing DOUBLE-FLOAT from LONG-FLOAT.
 ;; Still it's likely to be quite doable to get LONG-FLOAT support working
 ;; again, if anyone's sufficiently motivated.
 ; :long-float

 ;;
 ;; miscellaneous notes on other things which could have special significance
 ;; in the *FEATURES* list
 ;;

 ;; Any target feature which affects binary compatibility of fasl files
 ;; needs to be recorded in *FEATURES-POTENTIALLY-AFFECTING-FASL-FORMAT*
 ;; (elsewhere).

 ;; notes on the :NIL and :IGNORE features:
 ;;
 ;; #+NIL is used to comment out forms. Occasionally #+IGNORE is used
 ;; for this too. So don't use :NIL or :IGNORE as the names of features..

 ;; notes on :SB-XC and :SB-XC-HOST features (which aren't controlled by this
 ;; file, but are instead temporarily pushed onto *FEATURES* or
 ;; *TARGET-FEATURES* during some phases of cross-compilation):
 ;;
 ;; :SB-XC-HOST stands for "cross-compilation host" and is in *FEATURES*
 ;; during the first phase of cross-compilation bootstrapping, when the
 ;; host Lisp is being used to compile the cross-compiler.
 ;;
 ;; :SB-XC stands for "cross compiler", and is in *FEATURES* during the second
 ;; phase of cross-compilation bootstrapping, when the cross-compiler is
 ;; being used to create the first target Lisp.

 ;; notes on the :SB-ASSEMBLING feature (which isn't controlled by
 ;; this file):
 ;;
 ;; This is a flag for whether we're in the assembler. It's
 ;; temporarily pushed onto the *FEATURES* list in the setup for
 ;; the ASSEMBLE-FILE function. It would be a bad idea
 ;; to use it as a name for a permanent feature.

 ;; notes on local features (which are set automatically by the
 ;; configuration script, and should not be set here unless you
 ;; really, really know what you're doing):
 ;;
 ;; machine architecture features:
 ;; :x86
 ;; any Intel 386 or better, or compatibles like the AMD K6 or K7
 ;; :alpha
 ;; DEC/Compaq Alpha CPU
 ;; :sparc
 ;; any Sun UltraSPARC (possibly also non-Ultras -- currently untested)
 ;; :ppc
 ;; any PowerPC CPU
 ;; :hppa
 ;; any PA-RISC CPU
 ;; :mips
 ;; any MIPS CPU (in little-endian mode with :little-endian -- currently
 ;; untested)
 ;;
 ;; (CMU CL also had a :pentium feature, which affected the definition
 ;; of some floating point vops. It was present but not enabled or
 ;; documented in the CMU CL code that SBCL is derived from, and has
 ;; now been moved to the backend-subfeatures mechanism.)
 ;;
 ;; properties derived from the machine architecture
 ;; :control-stack-grows-downward-not-upward
 ;; On the X86, the Lisp control stack grows downward. On the
 ;; other supported CPU architectures as of sbcl-0.7.1.40, the
 ;; system stack grows upward.
 ;; Note that there are other stack-related differences between the
 ;; X86 port and the other ports. E.g. on the X86, the Lisp control
 ;; stack coincides with the C stack, meaning that on the X86 there's
 ;; stuff on the control stack that the Lisp-level debugger doesn't
 ;; understand very well. As of sbcl-0.7.1.40 things like that are
 ;; just parameterized by #!+X86, but it'd probably be better to
 ;; use new flags like :CONTROL-STACK-CONTAINS-C-STACK.
 ;;
 ;; :stack-allocatable-closures
 ;; The compiler can allocate dynamic-extent closures on stack.
 ;;
 ;; operating system features:
 ;; :linux = We're intended to run under some version of Linux.
 ;; :bsd = We're intended to run under some version of BSD Unix. (This
 ;; is not exclusive with the features which indicate which
 ;; particular version of BSD we're intended to run under.)
 ;; :freebsd = We're intended to run under FreeBSD.
 ;; :openbsd = We're intended to run under OpenBSD.
 ;; :netbsd = We're intended to run under NetBSD.
 ;; :sunos = We're intended to run under Solaris user environment
 ;; with the SunOS kernel.
 ;; :osf1 = We're intended to run under Tru64 (aka Digital Unix
 ;; aka OSF/1).
 ;; (No others are supported by SBCL as of 0.7.5, but :hpux or :irix
 ;; support could be ported from CMU CL if anyone is sufficiently
 ;; motivated to do so, and it'd even be possible, though harder, to
 ;; port the system to Microsoft Windows or MacOS X.)
 )
Something went wrong with that request. Please try again.