stumpwm-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[STUMP] Dependencies


From: David Bjergaard
Subject: [STUMP] Dependencies
Date: Tue, 01 Nov 2016 15:12:06 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux)

Hi All,

When I first started maintaining stumpwm, I was interested in knowing if people
were OK with extra dependencies in stumpwm.  This was before quicklisp was as
popular as it is now, and the build prescription didn't even mention it.

Things have changed now, and there have been a handful of contributions that
change the way stumpwm handles its internal loop.  There are also many, many
places where stumpwm re-invents the wheel for the sake of keeping dependencies
to a minimum.  The arguments for minimal dependencies are/were:
1. Less overhead for compiling (especially those unfamiliar with lisp 
development)
2. Less dependence on upstream changes that break their interface
3. Smaller dependencies -> greater freedom to run on multiple lisp flavors
4. Lower dependencies make it easier for distro managers to package and ship
   stumpwm outside of quicklisp/compiling with make

Quicklisp clearly nullifies argument 1.  Argument 2 is still an issue.  I've
been told that argument 3 is also moot with quicklisp since libraries in
quicklisp are supposed to run in multiple flavors.  In practice I've had the
opposite experience with the gui libraries  I've looked at (qt and smoke, and
the freetype renderer).  

While I believe philosophically that we should only depend on sbcl (the most
popular flavor), others in the community disagree.  Therefore I have agreed that
the mainline stumpwm will keep the minimal dependency design requirement, and
that paulownia (stumpwm 2.0) will have a much looser policy.  

I bring this up because there have been requests to:
1. remove dependence on cl-ppcre
2. add dependence on bordeaux-threads and alexandria

I think it warrants a discussion since the landscape has changes so much in the
last 3-4 years.

    David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]