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.