[cffi-devel] CFFI foreign library error pathname patch

[Zach Beane]

Luís Oliveira <luismbo at gmail.com> writes:

> On Sun, Dec 18, 2011 at 12:40 PM, Zach Beane <xach at 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