On Sun, 21 Apr 2024 07:45:16 +0200,
Timo Myyrä wrote:
> 
> On Fri, Apr 19 2024, Sebastien Marie wrote:
> 
> > For now, bumping stumpwm is the simpler, but I wonder if it would be
> > possible to use stumpwm somehow from source and let's sbcl compilation
> > to refresh the fasl files if updated. Timo, any idea ?
> >
> 
> I don't like the revision bump approach as why SBCL port should be
> changed for each libraries/application using it. That being said, I do
> not have anything better to offer here at the moment.
> 
> I'm not that well versed in the CL compilation process but looking at
> the SBCL manual [0] tells the FASL is tied to specific SBCL version. It
> also has configuration option to refresh stale FASL files which could be
> added system-wide in /etc/sbclrc.
> 
> So instead of current stumpwm build where it dumps the image, we could
> use the ASDF to compile the stumpwm to some directory (which directory?)
> and copy sources to other directory under /usr/local. And then create
> shell wrapper to /usr/local/bin/stumpwm to start the stumpwm using the
> asdf so that it would be recompiled if stale... But this recompilation
> is then done as user I think, so it can't refresh the package's own
> files but stores the updated FASL files to user-specific directory.
> 
> Is that something to aim for?
> 

This approach means that the first start of stumpwm, or after update of
sbcl, is long. Very logn. Minutes. User, probably, won't wait and start to
complain.

Also, we lose reproducible build and won't know does stumpwm compiled or not
on the system, until someone tries to use.

And test start only confirms that part of stumpwm is working.

So, I not sure that it is the right aproach at all.

I see much simpler approach: load all asd files from
/usr/local/lib/sbcl/contrib to put everything into produced image.

What do you think?

-- 
wbr, Kirill