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