On 2006-jan-05, at 09:28, James Bielman wrote:
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?
Yeah, your original suggestion was to use just a list, but I added a symbol to more easily differenciate it from the other possible list: (:framework foo). I think I'll go with the :OR suggestion, since it's probably more readable than just a list too.
b) A pathname, in which case CFFI doesn't try to find it andsimply 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?
Right, makes sense.
[about find-foreign-library and friends]
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.
Oh yes, find-foreign-library only searches in the directories that are passed to it as an argument (usually cffi:*foreign-library- directories*) not in the places that ldopen would search. But I suppose that could help in such custom search strategy anyway?
Well, find-foreign-library is probably a misnomer. It's more of a find-file-in-a-list-of-directories, really.
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?
While we're at it, I suppose that it could take a (:framework "foo") pair as well as a list of alternatives: (:or "lib1.so" "lib2.so")? And have it search in cffi:*foreign-library-directories* too.
Ie. load-foreign-library should handle its argument exactly the same way an "element" in define-foreign-library is handled. Sounds intuitive.