James Bielman wrote:
>This is emphatically *not* a reimplementation of UFFI's library code.
Ok. I'll shut up until I have time to investigate what it looks like.
>For system libraries, there should not ever be a need to specify a
>directory in DEFINE-FOREIGN-LIBRARY.
Please emphasize this in the documentation! I've seen enough software
documentation that does not explain how to actually use the software: what
functions are important, which are helpers, etc.
>*FOREIGN-LIBRARY-DIRECTORIES* exists as an escape hatch for users that
>want to extend this behavior
Same plead. Please state that in the documentation, so hopefully people will
not make wrong assumptions (e.g. "I need to set the directory because that's
what I'm used to with language XYZ" would be wrong here).
> (:linux (:or "libGL.so.1" "libGL.so"))
>The "libGL.so" entries are there as a fallback,
That makes a lot of sense. Please provide such examples/recommendations in the
documentation.
(which of course raises the problem of untested code: the developer probably
has libGL.so.1 on his machine and may not test the other case. So the other
case is an "educated guess" :).
>I disagree---these aren't wild guesses; the developer of a library
>should know what version of a library he is linking against, and
>document this information for each platform he's tested on.
[similar idea as here:]
>IMHO, if I'm going to link against symbols in a shared library, I had
>better be aware of what major version I'm loading.
My experience is different, perhaps because I've seen mostly bindings, not
applications. Bindings may have the property that they want to be as little
restrictive as possible. E.g. Bindings for postgres 7 may still work with
postgresql8, and vice-versa.
Regards,
Jorg Hohle.
_______________________________________________
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
