On Wed, 2006-01-04 at 21:08 +0000, Luís Oliveira wrote:
There's been some discussion on IRC about what CFFI's "smarter" foreign library interface should look like. I put together some code and here's what my attempt looks like:
(define-foreign-library opengl (:darwin (:framework "OpenGL")) (:unix (:alternatives "libGL.so" "libGL.so.1" #p"/myhome/mylibGL.so")) (:windows "opengl32.dll") ;; and a hypothetical example of a particular platform ;; where the OpenGL library is split in two. ((:and :some-system :some-cpu) "libGL-support.lib" "libGL-main.lib"))
The only thing I might like to change here is that :alternatives seems a little verbose to me. Would it be confusing to just re-use :or for this? Or just a list with no leading keyword symbol?
The library is then used with the following macro:
(use-foreign-library opengl)
Eventually we need to sit down and figure out exactly what the evaluation-time issues are on each Lisp. I know that currently, because of at least CMU CL, we need to load the foreign library at compile-time because the alien functions must be present to compile functions that call them.
I was wondering while stuck in traffic last night if we might be able to use a LOAD-TIME-VALUE in the CMU CL version of FOREIGN-FUNCALL to shift this requirement to load-time. I don't remember if any other Lisps need the function at compile time...
b) A pathname, in which case CFFI doesn't try to find it and simply passes its namestring to load-foreign-library.
I'm not sure I understand why the behavior for a pathname would be different than that of a namestring. If the pathname was relative, wouldn't it make sense to perform the same search if LOAD-FOREIGN-LIBRARY can't find it?
There are some functions that I'm not sure are worth exporting: find-foreign-library, find-and-load-foreign-library and find-darwin-framework.
Based on my experience with the UFFI interface, I think exporting FIND-* functions will lead to trouble. I see there being two scenarios for loading libraries:
1.) We want to "link" against a library, like -lfoo in gcc would do.
2.) We want to load a specific shared library at runtime, like a C user of 'dlopen' would do.
I think DEFINE-FOREIGN-LIBRARY is the right thing for scenario 1, where we don't really care where the library is, we just want to system to find it for us. If we export functions to turn system libraries into absolute pathnames, users will end up hardcoding those pathnames into their saved Lisp images as often happens when using UFFI.
Besides, it's not clear to me how we can perform the same search that a 'dlopen' would do without either trying to duplicate it, or trying it load it.
For scenario 2, if the user doesn't want to load the library from the standard locations, he will need a custom search strategy for locating the library anyway, so whatever function we supply isn't going to cut it, I think.
Also, maybe a functional interface to use-foreign-library could be useful?
How about making LOAD-FOREIGN-LIBRARY load a "logical" library defined with DEFINE-FOREIGN-LIBRARY if passed a symbol?
James