X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=src%2Fcold%2Fansify.lisp;h=50023dc29cee9f5e367155db47a26e769f58c288;hb=3eb39e017e52b5d704e7d33405c873af52a533fd;hp=f08332ec9381d9dbc17db093c433da1771a7b065;hpb=dfa55a883f94470267b626dae77ce7e7dfac3df6;p=sbcl.git

diff --git a/src/cold/ansify.lisp b/src/cold/ansify.lisp
index f08332e..50023dc 100644
--- a/src/cold/ansify.lisp
+++ b/src/cold/ansify.lisp
@@ -1,4 +1,4 @@
-;;;; patches to hide some implementation idiosyncrasies in our
+;;;; patches to work around implementation idiosyncrasies in our
 ;;;; cross-compilation host
 
 ;;;; This software is part of the SBCL system. See the README file for
@@ -9,6 +9,8 @@
 ;;;; 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.
+
+;;;; CLISP issues
 
 #+clisp
 (locally
@@ -29,21 +31,26 @@
   (export 'boolean "LISP")
   |#
 
-  ;; I gave up on using CLISP-1999-01-08 as a cross-compilation host because of
-  ;; problems that I don't have workarounds for:
-  (error "can't use CLISP -- no MAKE-LOAD-FORM")
-  (error "can't use CLISP -- no (FUNCTION (SETF SYMBOL-FUNCTION))")
-  )
+  ;; apparently fixed sometime in 2001, hurray!
+  #| (error "can't use CLISP -- no MAKE-LOAD-FORM") |#
 
-;;; CMU CL, at least as of 18b, doesn't support PRINT-OBJECT. In particular, it
-;;; refuses to compile :PRINT-OBJECT options to DEFSTRUCT, so we need to
-;;; conditionalize such options on the :NO-ANSI-PRINT-OBJECT feature in order
-;;; to get the code to compile. (It also fails to do anything useful with
-;;; DEFMETHOD PRINT-OBJECT, but that doesn't matter much, since it doesn't stop
-;;; the cross-compiler from working.)
-;;;
-;;; FIXME: SBCL 0.5.0 doesn't support PRINT-OBJECT either. SBCL 0.6.0 will,
-;;; at which time this conditional should go away.
+  ;; CLISP is still unsupported as a cross-compilation host because of
+  ;; these known problems:
+  (flet ((clisp-ouch (s) (error "can't bootstrap with CLISP: ~A" s)))
+    ;; These problems don't seem deep, and could probably be worked
+    ;; around.
+    #+nil (clisp-ouch "no (DOCUMENTATION X) when X is a PACKAGE")
+    #+nil (clisp-ouch "no (FUNCTION (SETF SYMBOL-FUNCTION))")))
+
+;;;; CMU CL issues
+
+;;; CMU CL, at least as of 18b, doesn't support PRINT-OBJECT. In
+;;; particular, it refuses to compile :PRINT-OBJECT options to
+;;; DEFSTRUCT, so we need to conditionalize such options on the
+;;; :NO-ANSI-PRINT-OBJECT feature in order to get the code to compile.
+;;; (It also fails to do anything useful with DEFMETHOD PRINT-OBJECT,
+;;; but that doesn't matter much, since it doesn't stop the
+;;; cross-compiler from working.)
 #+cmu
 (progn
   (warn "CMU CL doesn't support the :PRINT-OBJECT option to DEFSTRUCT.~%")
@@ -60,16 +67,29 @@
 ;;; /(READ-SEQUENCE *BUFFER* S :START 0 :END 3000)=3000
 ;;; /(READ-SEQUENCE *BUFFER* S :START 0 :END 15000)=1096
 ;;; /(READ-SEQUENCE *BUFFER* S :START 0 :END 15000)=0
-#+cmu ; FIXME: Remove SBCL once we've patched READ-SEQUENCE.
+#+cmu
 (progn
   (warn "CMU CL has a broken implementation of READ-SEQUENCE.")
   (pushnew :no-ansi-read-sequence *features*))
 
-;;; Do the exports of COMMON-LISP conform to the standard? If not, try to make
-;;; them conform. (Of course, ANSI says that bashing symbols in the COMMON-LISP
-;;; package like this is undefined, but then if the host Common Lisp were ANSI,
-;;; we wouldn't be doing this, now would we? "One dirty unportable hack
-;;; deserves another.":-)
+#+(and cmu alpha)
+(unless (ignore-errors (read-from-string "1.0l0"))
+  (error "CMUCL on Alpha can't read floats in the format \"1.0l0\".  Patch your core file~%~%"))
+
+;;;; general non-ANSI-ness
+
+(in-package :sb-cold)
+
+(defmacro munging-cl-package (&body body)
+  #-clisp `(progn ,@body)
+  #+clisp `(ext:without-package-lock ("CL")
+	     ,@body))
+
+;;; Do the exports of COMMON-LISP conform to the standard? If not, try
+;;; to make them conform. (Of course, ANSI says that bashing symbols
+;;; in the COMMON-LISP package like this is undefined, but then if the
+;;; host Common Lisp were ANSI, we wouldn't be doing this, now would
+;;; we? "One dirty unportable hack deserves another.":-)
 (let ((standard-ht (make-hash-table :test 'equal))
       (host-ht     (make-hash-table :test 'equal))
       (cl	  (find-package "COMMON-LISP")))
@@ -81,13 +101,16 @@
 	     (declare (ignore value))
 	     (unless (gethash key standard-ht)
 	       (warn "removing non-ANSI export from package CL: ~S" key)
-	       (unexport (intern key cl) cl)))
+	       (munging-cl-package
+		(unexport (intern key cl) cl))))
 	   host-ht)
   (maphash (lambda (key value)
 	     (declare (ignore value))
 	     (unless (gethash key host-ht)
 	       (warn "adding required-by-ANSI export to package CL: ~S" key)
-	       (export (intern key cl) cl))
+	       (munging-cl-package 
+		(export (intern key cl) cl)))
+	     
 	     ;; FIXME: My righteous indignation below was misplaced. ANSI sez
 	     ;; (in 11.1.2.1, "The COMMON-LISP Package") that it's OK for
 	     ;; COMMON-LISP things to have their home packages elsewhere.
@@ -123,8 +146,3 @@
 		       cl)
 		 (kernel:%set-symbol-package symbol cl))))
 	   standard-ht))
-
-#+(and cmu alpha)
-(unless (ignore-errors (read-from-string "1.0l0"))
-  (error "CMUCL on Alpha can't read floats in the format \"1.0l0\".  Patch your core file~%~%"))
-