[cffi-devel] New foreign library interface

[Hoehle, Joerg-Cyril]

Hi,

>For example, one way to handle this would be for LOAD-FOREIGN-LIBRARY
>to return a cookie
Cookie or "designator" is IMHO the way to go.
I feel it's a waste to reimplement in CFFI what UFFI already had to fuss around with directories, file extensions, features etc., reimplementing itself what's possibly in various Lisp implementations.

I nuked all of that crap in my own UFFI wrappers.  The "cookie" is UFFI's module name (typically a keyword, e.g. :odbc), and I assoc that one to the filename.
This association shall be maintained outside of UFFI/CFFI. It's the user who's setting this, and possibly the distribution maintainer (e.g. Debian).

That association is not even in package UFFI (I put it in USER). That way, it can be defined even before UFFI is loaded (e.g. .clisprc).  You don't need tricky constructions to the effect of being able to load UFFI first, patch the paths, then load system foo.  The proposals I've seen here for CFFI looked to me like they might get this wrong.


>   (define-foreign-library opengl
>     (:darwin  (:framework "OpenGL"))
>     (:unix    (:alternatives "libGL.so" "libGL.so.1"
>                              #p"/myhome/mylibGL.so"))
This is exactly what I criticize.
You, the programmer, do you know the library directories, extensions, version numbers of OpenGL on all platforms of the users of your library?
Do you know all the appropriate *features*?
Do you have means to test what you write yourself?  Presumably, you don't.

A Debian distributor might know, but not the code maintainer of an individual package. Therefore, again, a central algorithm & means of mapping makes more sense that people's wild guesses, different for each package and author.

I very much prefer
(defcfun "myfun" :module/library :my-cookie-designator :arguments ...)

Hmm, not sure I made myself clear, feel free to ask.

Regards,
	Jorg Hohle