Port CLSQL to CFFI without requiring cffi-uffi-compat

[dieggsy]

• CLSQL relies on UFFI, which was hosted on the same site as the original CLSQL: http://git.kpe.io/?p=uffi.git;a=summary. As far as I'm aware, it is also no longer maintained, though it is still available on quicklisp and ocicl.
• CFFI is a more modern and usually recommended library for FFI.
• CLSQL does have a way to use cffi-uff-compat, by loading :clsql-cffi, but it would be nice to use the CFFI API natively without the wrapper, since it removes a level of indirection.

This might also be a good chance to not :use :cffi but leave it in its own namespace, since IMO that leads to more readable code. Currently uffi is called with/without the package qualifier a bit randomly, which can get confusing at a glance.

[dieggsy]

Opening sub-issues for each supported RDBMS

I have started some of the required work on the master branch. The intent in fleshing out clsql-cffi to contain pure-cffi alternatives to clsql-uffi (instead of replacing it outright) is to allow incremental porting.

The highest priority for me is the ODBC interface since that's what I personally use and rely upon the most. I may be able to get to the other ones as well, but help is definitely welcome.

It's worth pointing out that for those using SQLite3, PostgreSQL, or MySQL, and not already relying on CLSQL, fukamachi/cl-dbi may be worth exploring.

[dieggsy]

Figured it's worth throwing out there - should c2ffi or cffi-grovel be considered in this effort? My first instinct is no due to added code/dependency complexity as well as somewhat lacking documentation, but open to discussion.

[dieggsy]

One problem with the current implementation of clsql-cffi:find-and-load-foreign-library is that :search-path is actually not preferred over default systems paths, so passing clsql:*foreign-library-search-paths* to it is not having the intended effect.

I'd rather not have to use the previous mechanism of manually appending pathnames to library filenames, so that the CFFI port can use cffi:define-foreign-library. I'm not sure where this leaves clsql:push-library-path though, since I don't see an easy way to prefer a path for a CFFI library outside of system mechanisms.

Maybe we have clsql-cffi:find-and-load-foreign-library temporarily set e.g. DYLD_LIBRARY_PATH, LD_LIBRARY_PATH, and (windows equivalent?) from clsql:*foreign-library-search-paths*. On second thought, messing with environment variables ourselves is probably not a good idea.

[luismbo]

There's cffi:*foreign-library-directories*.

[dieggsy]

@luismbo Thanks. I knew about it, but thought it did not behave in the same way as clsql:*foreign-library-serach-paths*. I'm pretty sure I was mistaken, though.

I thought that clsql:*foreign-librray-search-paths* would be preferred over system paths, but this is not the case. I think it only appeared that way to me because of the specifics of my machine's ODBC configuration.

With this in mind, I think that makes just going ahead with cffi:define-foreign-library and relying on standard CFFI behavior perfectly viable and simpler than I made it out to be.