Re: How CLSQL finds and loads foreign libraries

Hi,

here's what I did in my UFFI wrappers:

The local programmer is responsible for maintaining a list of translations as follows:

;(push (cons "odbc" "odbc32.dll") uffi::*module-translations*)
;(push (cons "odbc" "/usr/lib/libodbc.so.1") uffi::*module-translations*)
;(push (cons "postgresql" "/usr/lib/libpq.so.3") uffi::*module-translations*)
;(push (cons "postgresql" "libpq.so.3") uffi::*module-translations*);works equally well on Linux
;(push (cons "clsql-uffi" ".../clsql-3.0.3/uffi/uffi.so") uffi::*module-translations*)

I.e., it's settable as soon as the UFFI package is loaded, but before the cl-sql, cl-gd etc. get loaded. My uffi:find-foreign-library wrapper is fake.

This works, because I arranged for the .fas files generated by CLISP to *not* contain a path to a library. Instead, the *module-translations* will be queried at load-time, which is when the foreign functions will be instanciated in CLISP.

That .fas file issue was important to me. I did not want to require programmers to modify a single file of some distribution, e.g. cl-sql. And I wanted the .fas files to be distributable.

Of course, that does not solve the Debian issue, because it is not prepared to cover multiple directories itself, unless there were some package install-time stuff.

I'm not sure if I would appreciat the debian installer to write some Lisp file that would set a directory, or add to an existing file containing module translations.

Searching a couple of directories and having packages work equally well when installed from .tar.gz or frmo Debian .deb is valuable IMHO, because I find myself in a situation where I have the debian packages, but also a newer copy from .tar.gz which I use to contribute patches. That doesn't sound like the ideal world, don't you think?

Regards,
	Jorg Hohle.