[cffi-devel] uffi.asd vs uffi-compat.asd

[Daniel Herring]

On Fri, 21 Aug 2009, Cunningham, Jeffrey K. wrote:
> From: Luís Oliveira
>> As Daniel Herring hinted, one way you can solve this problem is to
>> setup asdf:*central-registry* such that UFFI's uffi.asd takes
>> precedence over the clbuild/systems/uffi.asd one. Would that work for
>> you?
>
> You are right - it would solve the problem. But it leaves library 
> compatibility in that awful state that requires too much arcane 
> information to be known to write decent auto-setup tools. But don't you 
> think that in the long run Lisp libraries ought to work together without 
> all kinds of special exceptions? Its one of the things people always 
> complain about with Lisp. Just my two cents.

[It looks like Elephant needs fixing; the rest of this email explains my 
view on the "dll hell" Jeff describes.]

The situation you describe is common to all library frameworks in all 
languages I'm aware of.  It can be alleviated by versioned libraries; but 
even versioning falls down when two libraries want to use different 
versions of a common base lib.

There seem to be two approaches to solving it in C/C++; I think they apply 
to lisp with only minor modifications.  One is to always statically link 
dependencies; commercial software usually comes with all dependencies 
included in the installer or the executable itself; Elephant could include 
uffi in its tarball and specify it directly.  This solution is really only 
good for finished products, and it makes system-wide library updates 
rather difficult.

The other approach, championed by GNU Autoconf, is to have the 
installation process probe the system it is being added to.  This gives 
the packager an opportunity to paper over common versioning issues and the 
chance to fail gracefully.  It also provides a human installer a good 
opportunity to customize the package for local needs.

I think the way forward is to move away from Common Lisp's traditional 
load-and-compile-and-everything-else-in-one-step approach.  The Common 
Lisp user needs to be able to configure packages before building them, to 
be able to specify which dependencies to use on a package-by-package 
basis.  The CL user also needs to be able to build and test packages 
before installing them.  And any auto-rebuilding of dependencies is broken 
except in the simple case where all final products use the same set of 
dependencies and incremental recompile gives the same result as a full 
recompile (individually, each is rarely true in CL).

The next step is for people to differentiate between "stock" and 
"localized" packages.  Very few people compile even a small minority of 
the programs and libraries on their computer.  Whether Apple, BSD, Linux, 
or Microsoft, a distribution maintainer has installed a core set of tools 
into default locations (e.g /bin and /usr/bin).  End-users are then 
instructed to install custom applications and libraries into separate 
areas (e.g. /usr/local/bin, ~/local/bin).  In this way, system-wide 
changes can be safely pushed, and only custom stuff risks breakage.

That's enough rambling for now,
Daniel