Re: [STUMP] Some patches to remove implementation-dependent code

[Ben Spencer]

On Sun, Nov 13, 2011 at 05:20:47PM -0500, Vladimir Sedach wrote:
> It actually doesn't fail - it loads portable-clx. I have a moral
> aversion to the clx libraries bundled with CLISP and CMUCL. It's extra
> effort for maintainers of applications and libraries that need an X
> interface, and extra effort for the implementation maintainers.
> Lose-lose all the way around. Particularly annoying when you have to
> try to fix bugs and get the fixes pushed upstream.
> 
> That's part of the problem I talked about above. Use quicklisp to load
> the latest portable-clx for all implementations. Fixes to clx should
> be pushed upstream to clx, and implementation fixes should be pushed
> to the implementation. It doesn't make sense having the
> application/library be responsible for working around compiler bugs
> when you're working with free software.

While the idea of insisting on the latest version of portable-clx is
attractive [0], I see a number of potential issues:

 * It would cause upheaval for distros, who use their own dependency
   tracking rather than quicklisp.  Debian, for example (last time I
   checked) provides portable-clx for SBCL but assumes that you want
   to use new-clx if you're using CLISP.

 * CLISP users may prefer to use new-clx.  I don't know if anybody's
   actually benchmarked it, but it seems quite possible that new-clx
   (which is an FFI to xlib) is quicker than bytecode-compiled
   portable-clx.

 * I believe ECL doesn't currently work with portable-clx.  Yeah, ok,
   this is their fault for maintaining a fork rather than submitting
   patches upstream, but there you are.

 * Assuming that there will only ever be one canonical implementation
   of clx is a bit limiting.  Suppose someone comes along and
   implements an awesome new clx that achieves portability by pulling
   in dependencies like iolib?  Or an FFI onto xcb?  Or a clx for ABCL
   that uses some Java X library?  Choice and competition is good.

I'd love to hear opinions on this matter from other people,
particularly distro maintainers and CLISP users.


> > clisp_BUILDOPTS=-K full -on-error exit < ./make-image.lisp
> >
> > Not sure if that makes any difference?
> 
> I'll have to double-check. The reason it has to load clisprc is
> because that's where quicklisp should normally be loaded.

Yep, that was the reason behind my change too.


Ben


[0] Actually, given that portable-clx is pretty much maintainerless
    I've even considered having a 'blessed' version that we maintain
    specifically for stumpwm.