GNU bug report logs - #33753
[PATCH 1/3] gnu: Add stumpwm-contrib.

Previous Next

Full log

Message #50 received at 33753 <at> debbugs.gnu.org (full text, mbox):

From: Nam Nguyen <namn <at> berkeley.edu>
To: 33753 <at> debbugs.gnu.org
Subject: Re: [bug#33753] stumpwm-contrib
Date: Tue, 25 Dec 2018 23:13:21 -0800

I did some investigating by querying within stumpwm.

C-t ; brings up a stumpwm prompt.
---8<------------------------------------------------------------
eval-line (print *module-dir*)

/gnu/store/...stumpwm-18.11-lib/.stumpwm.d/modules/
---8<------------------------------------------------------------

It seems to set *module-dir* at build time to be
/gnu/store/...stumpwm-18.11-lib/.stumpwm.d/modules/. However, this .stump.d
doesn't exist and it was created when stumpwm was compiled. There are
also potentially a FHS assumption with (getenv "HOME") and it happens to
evaluate to the /gnu/store item.

StumpWM gives option #1 of setting module-dir at build time of
StumpWM. I could try patching
---8<------------------------------------------------------------
> (pathname-as-directory (concat (getenv "HOME") "/.stumpwm.d/modules"))
---8<------------------------------------------------------------
in order to store the modules at some standard, system-wide location? Hard
coding it as /var/guix/profiles/per-user/user/guix-profile/share/common-lisp
is incorrect because guix won't build as the user. Maybe I can force stumpwm
and the stumpwm-contrib modules to use the same stumpwm library. This seems
tricky/impossible, though, since they are all individual modules.

StumpWM also offers option #2 of calling set-module-dir to set this
variable at run-time in ~/.stumpwmrc. This is how it currently works and
it seems more simple.
---8<-------------------  ~/.stumpwmrc --------------------------
(set-module-dir "~/.guix-profile/share/common-lisp/sbcl-bundle-systems")
---8<------------------------------------------------------------

*module-dir* is essentially a seed for *load-path*, which is where the
files like cpu.asd and cpu--system.fasl are. With the current setup,
load-path is populated correctly.
---8<------------------------------------------------------------
eval-line (print *load-path*)

/gnu/store/stumpwm-cpu/lib/sbcl/"
...
/gnu/store/stumpwm-mem/lib/sbcl/"
---8<------------------------------------------------------------

Option #3 is to use "add-to-load-path", but that seems similar to
Option #1. I suppose this is a matter of investigating how stumpwm
handles its modules/extensions. What I know thus far points me to err
toward setting module-dir at run-time, since it is a one-liner.

Relevant snippets from module.lisp
(https://github.com/stumpwm/stumpwm/blob/master/module.lisp)

---8<------------------------------------------------------------
(defvar *module-dir*
  (pathname-as-directory (concat (getenv "HOME") "/.stumpwm.d/modules"))
  "The location of the contrib modules on your system.")

(defun build-load-path (path)
  "Maps subdirectories of path, returning a list of all subdirs in the
  path which contain any files ending in .asd"
  ...

(defvar *load-path* nil
  "A list of paths in which modules can be found, by default it is
  populated by any asdf systems found in `*module-dir*' set from the
  configure script when StumpWM was built, or later by the user using
  `add-to-load-path'")

(defun set-module-dir (dir)
  "Sets the location of the for StumpWM to find modules"
  (when (stringp dir)
    (setf dir (pathname (concat dir "/"))))
  (setf *module-dir* dir)
  (init-load-path *module-dir*))
---8<------------------------------------------------------------

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.