Creating a FreeBSD StumpWM package

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Creating a FreeBSD StumpWM package

Joseph Mingrone
Hello,

StuwmpWM used to have a FreeBSD package, but it became stale, then
broken and was eventually removed from the FreeBSD ports tree.  It would
be nice for FreeBSD users to be able to get stump up and running with a
simple `pkg install stumpwm`, so I'm attempting to get the port/package
working again.  I also notice there is no OpenBSD or pkgsrc package, so
if this package succeeds it might be a helpful template for them.

This is what works now.  It pulls in all the dependencies, builds and
installs the executable, installs the lisp source and stumpwm.asd in the
common lisp central registry.  The problem starts when stump is run.  It
just starts sbcl and shows the repl with no errors.  Any suggestions for
debugging?

Nothing stands out (to me) in the build log.
http://pkg.awarnach.mathstat.dal.ca/data/11amd64-default/2017-08-13_18h13m27s/logs/stumpwm-20170807.log

Thanks for any insight,

Joseph

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

signature.asc (979 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Creating a FreeBSD StumpWM package

Joseph Mingrone
Joseph Mingrone <[hidden email]> writes:

> Hello,

> StuwmpWM used to have a FreeBSD package, but it became stale, then
> broken and was eventually removed from the FreeBSD ports tree.  It would
> be nice for FreeBSD users to be able to get stump up and running with a
> simple `pkg install stumpwm`, so I'm attempting to get the port/package
> working again.  I also notice there is no OpenBSD or pkgsrc package, so
> if this package succeeds it might be a helpful template for them.

> This is what works now.  It pulls in all the dependencies, builds and
> installs the executable, installs the lisp source and stumpwm.asd in the
> common lisp central registry.  The problem starts when stump is run.  It
> just starts sbcl and shows the repl with no errors.  Any suggestions for
> debugging?

> Nothing stands out (to me) in the build log.
> http://pkg.awarnach.mathstat.dal.ca/data/11amd64-default/2017-08-13_18h13m27s/logs/stumpwm-20170807.log

> Thanks for any insight,

> Joseph

This main problem has been solved and the package is mostly usable [1].
The executable was being installed with `install -s ...`, which strips
the executable.  Clearly that was doing something wrong because the size
of the stumpwm executable went from 55 MB to 233 KB.

Regards,

Joseph

[1] One issue is that the executable is referring to paths used during
the package building, that are not correct when it's installed on the
user's machine.  Hopefully I'll figure that one out.

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

signature.asc (979 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Creating a FreeBSD StumpWM package

Javier Olaechea
If the goal is to get something one can invoke from the shell or xinitrc, I use cl-launch[0] plus the following script. You would have have to place StumpWM sources somewhere where ASDF can find them and and copy the following script (maybe change the Q arg to +Q so that it doesn't try to fetch StumpWM from quicklisp).

```stumpwm-loader
#!/usr/bin/cl -Q -sp stumpwm -E main

(defun main (argv)
  (if argv
      (stumpwm (elt argv 0))
      (stumpwm)))
```

[0]: http://cliki.net/cl-launch

On Sun, Aug 13, 2017 at 9:47 PM, Joseph Mingrone <[hidden email]> wrote:
Joseph Mingrone <[hidden email]> writes:

> Hello,

> StuwmpWM used to have a FreeBSD package, but it became stale, then
> broken and was eventually removed from the FreeBSD ports tree.  It would
> be nice for FreeBSD users to be able to get stump up and running with a
> simple `pkg install stumpwm`, so I'm attempting to get the port/package
> working again.  I also notice there is no OpenBSD or pkgsrc package, so
> if this package succeeds it might be a helpful template for them.

> This is what works now.  It pulls in all the dependencies, builds and
> installs the executable, installs the lisp source and stumpwm.asd in the
> common lisp central registry.  The problem starts when stump is run.  It
> just starts sbcl and shows the repl with no errors.  Any suggestions for
> debugging?

> Nothing stands out (to me) in the build log.
> http://pkg.awarnach.mathstat.dal.ca/data/11amd64-default/2017-08-13_18h13m27s/logs/stumpwm-20170807.log

> Thanks for any insight,

> Joseph

This main problem has been solved and the package is mostly usable [1].
The executable was being installed with `install -s ...`, which strips
the executable.  Clearly that was doing something wrong because the size
of the stumpwm executable went from 55 MB to 233 KB.

Regards,

Joseph

[1] One issue is that the executable is referring to paths used during
the package building, that are not correct when it's installed on the
user's machine.  Hopefully I'll figure that one out.

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel




--
"I object to doing things that computers can do." — Olin Shivers

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Creating a FreeBSD StumpWM package

Joseph Mingrone
Javier Olaechea <[hidden email]> writes:
> If the goal is to get something one can invoke from the shell or xinitrc, I
> use cl-launch[0] plus the following script. You would have have to place
> StumpWM sources somewhere where ASDF can find them and and copy the
> following script (maybe change the Q arg to +Q so that it doesn't try to
> fetch StumpWM from quicklisp).

> ```stumpwm-loader
> #!/usr/bin/cl -Q -sp stumpwm -E main

> (defun main (argv)
>   (if argv
>       (stumpwm (elt argv 0))
>       (stumpwm)))
> ```

> [0]: http://cliki.net/cl-launch

Hello Javier,

I like the idea of not bundling SBCL and Stump into a large executable.
A small package makes sense when the packaging tools ensure the
dependencies are installed properly.  cl-launch looks useful and I may
revisit it at some point, but since Stump is now restricted to SBCL, I
ended up using a simple shell script.

stumpwm
---
#/bin/sh

sbcl --no-sysinit --no-userinit --load %%PREFIX%%share/stumpwm/load.lisp
---

share/stumpwm/load.lisp
---
(in-package :cl-user)

(require :asdf)

(setf asdf:*central-registry*
       (list* '*default-pathname-defaults*
              #p"%%ASDF_REGISTRY%%"
              asdf:*central-registry*))

(require :stumpwm)
(stumpwm:stumpwm)

(quit)
---

Thanks,

Joseph

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

signature.asc (979 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Creating a FreeBSD StumpWM package

Joseph Mingrone
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
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

signature.asc (979 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Creating a FreeBSD StumpWM package

David Bjergaard
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 <[hidden email]> 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
> [hidden email]
> https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel
Reply | Threaded
Open this post in threaded view
|

Re: Creating a FreeBSD StumpWM package

Joseph Mingrone
David Bjergaard <[hidden email]> writes:
> 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

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-*/

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel

signature.asc (979 bytes) Download Attachment