[cffi-devel] New foreign library interface

[James Bielman]

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