[cffi-devel] Extending defcfun and friends with extra options

[Luís Oliveira]

On 30/01/07, Green Bryan - bgreen <Bryan.Green at acxiom.com> wrote:
> [,,,] But, why not have
> someone pick cdecl or stdcall with as as option  to load-library?

Doing that at runtime might not be straightforward as it implies
recompiling all of the DEFCFUNs at library load time in order to have
them match the appropriate calling convention.

Anyway, we can have this as an option for define-foreign-library:

  (define-foreign-library (foo :general-opt1 ...)
    (:windows "foo.dll" :calling-convention :stdcall)
    (:unix "foo.so"))

At macroexpansion-time, this would set the :general-opt1 for foo
always, and the :calling-convention only when cffi-features:windows is
present in *features*, i.e. when you're compiling on a windows
machine. (This, btw, would require slightly backwards incompatible
adjustments to the syntax.)

Then you'd have:

  (defcfun ("foo_function" :library foo) :rettype
    ...)

I've been thinking a little bit on how to best deduce the library when
the :library option is not present (less typing for people that don't
use bindings generators; also, see the other thread about DLL
namespaces). The ideas I have for that so far are:

  b) define-foreign-library option that associates a package with that library
  c) similar option that matches a prefix with the function name

I suppose these two could be used in conjunction. For instance, a
function name would have to both be in package-foo and begin with
"foo_" to be considered part of the foo library and inherit its
options. In any case, the default would be the same no
define-foreign-library options and no :library option means looking up
the function names at library load time.

Re-reading what I just wrote makes me wonder whether this too much
overkill just to avoid typing ":library foo" repeatedly.

Ah, I forgot about defcvar. (defcvar name type &key read-only-p) For
consistency, I suppose we should put the options in the name argument
but it already has keyword arguments.

  ;; #1 -- defcvar used to have that docstring argument
  ;; looks more like cl:defvar when no options are provided.
  (defcvar (name :opt1 ... :opt2 ...) :some-type
    "docstring here")

  ;; #2 -- cleaner, backwards-compatible
  (defcvar name :some-type :opt1 ... :opt2 ...)

I think I'm inclined towards #1.

Enough brain dumping for today.

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/