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

[Vladimir Sedach]

Hi Ben,

> Thanks for the patches.  Some of them intersect with the build system
> / README work I pushed this morning - sorry about that, could have
> saved you some work if I'd done it earlier.

No problem. I was planning on taking a look at your repository in
December (my time-scale for working on free software is glacial...)

> 0001 Removed unused stumpwm-system package declaration.
>
> Is there anything particularly wrong with this idiom?  And if we're
> not using it, should we qualify defsystem with asdf: ?

Just extra code that's not essential.

> 0002 Don't assume that clisp doesn't need CLX
>
> The problem here is that asdf doesn't know how to load clisp's builtin
> clx, so the build will fail if you want to use that.

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.

> I am certainly keen to get rid of cruft we don't need, but at the same
> time I'd rather not gratuitously break anybody's setup.  Although we
> can probably assume that SBCL users will be using the latest version
> of portable-clx, I think CLISP users are currently more likely to be
> using new-clx.

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.

> 0005 In Makefile, load make-image.lisp with -i flag for CLISP so that
> .clisprc is run first.
>
> I did this as:
>
> 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.

Thanks,
Vladimir