Post by David BjergaardThanks so much for bundling this for FreeBSD. I think its important that it be
available anywhere X11 is the principle way of managing windows.
The debate of dumping the sbcl world to a binary named sbcl vs loading the
source is roughly equivalent to the static vs dynamic linking debate. I come
down on the static side (which is what stumpwm builds to by default). Running
stumpwm via sbcl does the same thing, it just puts the compiled fasl files in
~/.cache/common-lisp/sbcl-*/ and then loads and recompiles them as needed.
Overall the memory footprint will be the same, but you split stumpwm as an
application from sbcl.
From a user perspective (especially users unfamiliar with lisp) a binary named
stumpwm makes more sense than a stumpwm.lisp file that is loaded from a sbcl
runtime.
As far as hosting stumpwm.texi: that file is derived from the stumpwm sources
when it is built (in conjunction with stumpwm.texi.in). Storing it in the repo
1. Users who want to extend the manual don't know which one to edit
2. When stumpwm is recompiled, the manual will drift from the sources if
stumpwm.texi is not regenerated
3. If a user edits stumpwm.texi.in (see 1) their edits will get blown away when
they rebuild the program.
For packaging purposes, you can run "make travis" to just build stumpwm (no
generation of the manual). Is it a burden to have sbcl when you package the
release?
As far as releases go: I need to get back to defining a set of features to aim
for a release. Its been a while so releasing a new version makes sense.
Sincerely,
David
Hi David,
I am pleased to be able to chip in with a relatively tiny contribution.
Thanks for your feedback and for maintaining StumpWM.
I have not committed yet, and there have been some changes since my last
post. Right now, my local StumpWM port [1] pulls in SBCL and the other
dependencies (cl-ppcre, alexandria, and clx) and uses a simple CL
framework that other FreeBSD CL ports use [2]. CL ports have associated
CL implementation ports. For example, there is devel/cl-alexandria and
devel/cl-alexandir-sbcl, which installs the SBCL fasl files for
alexandria. Since StumpWM only supports running under SBCL, the port
pulls in the -sbcl dependencies and conforms to the framework itself,
except that it directly installs the fasl files instead of having an
associated x11-wm/stumpwm-sbcl. I do not foresee these fasl files
changing except when users upgrade the package. This means no fasl
files will be generated under ~/.cache/common-lisp/sbcl-*/ [3] and the
package is only made up of the source, fasl files, and a few small,
miscellaneous files. From a user perspective, they still get an
executable, but it is tiny and simply contains
```
#/bin/sh
/usr/local/bin/sbcl --eval "(in-package :cl-user)" \
--eval "(require :stumpwm)" \
--eval "(stumpwm:stumpwm)" \
--eval "(quit)"
```
and the package is under 3 MB instead of something like 65 MB. I agree
there are advantages to static linking (or in our case, bundling one
large executable), but assuming package maintenance can stay on top of
the usual annoyances that can arise with dynamic linking, I think this
is a good solution. If I am wrong and there is breakage, I will just
revert back to the bundled executable.
With respect to storing stumpwm.texi in the repository, after spending
more time on this and changing strategies, I withdraw what I said.
I have also discovered a better way to base packages on git commits
after a tagged release, so we are less constrained to releases.
Thanks again for your feedback. If you see problems with this approach
and have time, please tell me how I am misguided.
Joseph
[1] FreeBSD terminology for a package's /blueprints/
[2] https://svnweb.freebsd.org/ports/head/devel/cl-asdf/files/asdf-init.lisp?revision=340872&view=markup
[3] Loading personal modules in ~/.stumpwmrc will still generate fasl
files under ~/.cache/common-lisp/sbcl-*/