Hi Joseph, Thanks 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 causes a few problems: 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 Joseph Mingrone <j...@ftfl.ca> writes: > The package is tested and just about ready. Based on Javier's > suggestion, it is quite simple and mostly just installs the lisp source. > But, SBCL needs to be added as a build-time depenendency and StumpWM > needs to be built during package building just to process > stumpwm.texi.in to build the info file. > > What do you think about storing the texi file in the repository? > > The generated file isn't much larger and doesn't seem to change often, > so it /shouldn't/ be a burden to store both. > > It would be nice to align package releases with upstream, but since > there have been lots of improvements since 1.0.0, the planned package is > following commits (currently stumpwm-20170807 based on 49fdf94). Are > there plans for a new release in the near future? If so, we could wait > before releasing the package. > > Thanks, > > Joseph > _______________________________________________ > Stumpwm-devel mailing list > Stumpwm-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/stumpwm-devel _______________________________________________ Stumpwm-devel mailing list Stumpwm-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
