Luís Oliveira <luis...@gmail.com> writes: > On Sun, Dec 18, 2011 at 12:40 PM, Zach Beane <x...@xach.com> wrote: >>> OK, and so you'd like to get a hold of >>> "/maybe/some/path/to/libfoo.so.x" or whatever. Hmm, so maybe in >>> try-foreign-library-alternatives we could store the first alternative >>> since that should usually be something like "libfoo.so.x". >> >> It would be nice to have all the alternatives. > > We could store the definition s-exp. > > ;;; (define-foreign-library opengl > ;;; (:darwin (:framework "OpenGL")) > ;;; (:unix (:or "libGL.so" "libGL.so.1" > ;;; #p"/myhome/mylibGL.so")) > ;;; (:windows "opengl32.dll") > ;;; ;; an hypothetical example of a particular platform > ;;; ((:and :some-system :some-cpu) "libGL-support.lib") > ;;; ;; if no other clauses apply, this one will and a type will be > ;;; ;; automagically appended to the name passed to :default > ;;; (t (:default "libGL"))) > > In this case, the error's LIBRARY-SPECIFICATION slot (or something > along those lines), could hold a string, a pathname, or s-exps whose > CARs are one of :OR, :DEFAULT, or :FRAMEWORK. > > But it's a bit messy. Wouldn't it be easier to deal with a single > string? At first sight, it seems unlikely that some of the > alternatives in an :OR clause would hold more project information than > others. (Except perhaps for the version, which should be in the first > alternative, but sometimes isn't.) > > In this example, said string would be > "/path/to/OpenGL.framework/something/something.dylib", "libGL.so", > "opengl32.dll" on OS X, Unix, and Windows, respectively.
Ok, that makes sense, and seems sufficient to find a missing library in some system-specific database. Zach _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
