The following patch "fixes" CLX such that SBCL (or, more precisely, and SBCL that is configured to have :little-endian on its *features* list) no longer sees the old-style eval when conditions and makes clx.asd stop breaking the compilation due to the subsequent style-warning issued by SBCL:
diff -rN -u old-clx/depdefs.lisp new-clx/depdefs.lisp --- old-clx/depdefs.lisp 2011-03-11 08:31:55.000000000 -0800 +++ new-clx/depdefs.lisp 2011-03-11 08:31:55.000000000 -0800 @@ -141,7 +141,7 @@ ;;; You must define this to match the real byte order. It is used by ;;; overlapping array and image code.
-#+(or lispm vax little-endian Minima) +#+(or lispm vax (and (not sbcl) little-endian) Minima) (eval-when (eval compile load) (pushnew :clx-little-endian *features*))
Any objections to that patch?
thanks,
Cyrus
On Feb 18, 2011, at 1:40 PM, Cyrus Harmon wrote:
Forgive me if you've heard me rant about this before, but there is a mutual incompatibility between CLX, trivial-features (which, for me at least, gets pulled in whenever I try to use CFFI) and SBCL. The problem is that trivial-features puts :little-endian on *features* and CLX has the following code in defdeps.lisp:
#+(or lispm vax little-endian Minima) (eval-when (eval compile load) (pushnew :clx-little-endian *features*))
These old-style eval-when conditions cause SBCL to issue a warning, which causes ASDF to stop compiling CLX. There are many workarounds to this, such as loading CLX before CFFI and there are many possible fixes (such as making SBCL less pedantic or making ASDF not stop on warnings of this kind, etc...) But it seems to me that either fixing the CLX source code such that it is more tolerant of SBCL's pedantry or, alternatively, picking less common names for the *features* in trivial-features would be a good thing. I don't really have a preference, but it would be nice if the CLX and trivial-features maintainers would play nice with each other such that, at least when using SBCL, one can load trivial-features and then CFFI.
I'm certainly open to other suggestions, but I've grown tired of working around this particular problem.
thanks,
Cyrus
clx-devel mailing list clx-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/clx-devel