[cffi-devel] define-foreign-library behavior

[Stephen Compall]

On Sat, 2006-05-13 at 15:01 -0400, hbabcockos1 at mac.com wrote:
> (define-foreign-library libc
> 	(t (:default "libc")))
> (use-foreign-library libc)
> 
> But this doesn't:
> 
> (define-foreign-library libc
> 	(t (:or "libc" "libc.so.6")))
> (use-foreign-library libc)
> 
> This seems to be because load-foreign-library doesn't attempt to  
> guess the appropriate suffix for the library name when used with :or.  
> This is the documented behavior but it could be a little confusing  
> since the second example appears to the naive (like me) to be a super- 
> set of the first example.

Consider instead that library spec clauses have an evaluation rule that
supports composition of useful, yet orthogonal operators.  :OR
and :DEFAULT behavior should not intersect in such a scheme.

> Also:
> (define-foreign-library libc
> 	(:unix (:or "libc.so.6"))
> 	(t (:default "libc")))
> (use-foreign-library libc)
> 
> Doesn't work since OS-X is unix, but not linux. Maybe after failing  
> on the specific case (i.e. unix), it could fall back to the general  
> case?

I won't state a preference on this, except that the current behavior
seems chosen to be much like that of COND, CASE, and other such CL forms
with test-expr clauses.

-- 
Stephen Compall
http://scompall.nocandysw.com/blog
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20060513/575eab59/attachment.sig>