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-de...@common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/clx-devel _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
