I have been dodging the issue of configuration for LLA for a while, but eventually I had to come up with a solution for the revised version that I pushed to Github yesterday.
LLA users may need to configure two things: the location and name of libraries that they want to use, and whether LLA should use 64-bit integers to interface with BLAS/LAPACK (this is rarely needed, even on 64-bit platforms, as many implementations still use 32-bit integers). In the previous versions of LLA, I tried to do this with read-time conditionals (based on trivial-features) but this was not satisfactory as it is impossible to figure out the list of libraries from nothing but the platform information — for example, a Linux user could use ATLAS or MKL.
I read Maintaining Portable Lisp Programs by Christophe Rhodes and also asked on cl-pro, where I got a lot of good suggestions and decided to follow the advice of Pascal Costanza. This is how configuration works at the moment for LLA:
-
The user may define a variable
*lla-configuration*
in theCL-USER
package. The variable should contain a plist of configuration options, eg:libraries
. The variable does not need to be bound, and it can be NIL or incomplete: the user only needs to deal with configuration when he wants to override the defaults of the library. LLA makes an effort to come up with sensible platform-specific defaults. -
When loaded/compiled, LLA checks whether
cl-user::*lla-configuration*
is bound, and if it is, it uses the corresponding values. If the variable is not bound or doesn't contain the desired property, a default value is used instead.
Internally, some features are implemented by pushing symbols like lla::int64
to *features*
. I have do admit that I didn't even consider the possibility of package qualifiers in read-time conditionals before I read the appropriate sections of the Hyperspec, but in retrospect it makes perfect sense as it helps to avoid name clashes. LLA also removes its own symbols from *features*
if they don't belong there: this means that you can reload the library with a different configuration without restating your CL image.
One thing that's always struck me as annoying about the use of CL-USER variables like this is that when you define them in your cl init file, downstream you get warnings about duplicate definitions for the same variable, if you defvar them in your source code.
ReplyDeleteIs there a good idiom to avoid this?
Hi Robert: but I don't defvar them again. I use boundp to check if the variable is bound, and getf to access it if it is.
ReplyDelete