[xmonad] Ubuntu, Xmonad, and Xinerama

[Don Stewart]

droundy:
> On Wed, Mar 19, 2008 at 07:16:03PM +0200, Roman Cheplyaka wrote:
> > * David Roundy <droundy at darcs.net> [2008-03-19 12:09:41-0400]
> > > On Wed, Mar 19, 2008 at 06:02:14PM +0200, Roman Cheplyaka wrote:
> > > > * Christopher Sanner <hitch at propheteer.org> [2008-03-19 11:24:58-0400]
> > > > >
> > > > > David Roundy wrote:
> > > > >> Someone really should figure out how to build software reliably using ghc
> > > > >> packages.  This is just embarassing.  And then we could tell the cabal
> > > > >> folks how to do this.
> > > > >>
> > > > >> I understand that dons is reluctant to load up ghc every time xmonad loads,
> > > > >> but perhaps we could figure out some way to track the modification date of
> > > > >> the xmonad and/or xmonad-contrib packages and recompile if those have
> > > > >> changed.
> > > > >>   
> > > > > alternatively, could the installation of xmonad or xmonad-contrib could  
> > > > > include post-install actions to kick off recompiling?
> > > > 
> > > > Note that xmonad can be installed system-wide (say, with
> > > > --prefix=/usr/local) and going to every user's .xmonad does not look
> > > > sane.
> > > 
> > > As a workaround, however, we could install an empty file as /etc/xmonad,
> > > and then we could trigger a recompile whenever this file is newer than
> > > xmonad.hs.  It might be easier to do this than to figure out where ghc
> > > stores its packages to look at their timestamp (which would be the right
> > > thing to do).
> > 
> > 1. (Just in case someone will take this approach) Programs (other than
> >    editors or package managers) should avoid touching /etc, I believe.
> >    So you better use /var.
> > 2. In case of --user install, that file should be placed under
> >    ~/.xmonad. It may seem that just touching xmonad.hs is simpler,
> >    but... It's not very ethical from my point of view.
> 
> Agreed.  What do you think of my patch to check the timestamps on the ghc's
> package files?

I'm not keen on this. We already decided to restrict the recompilation
checking, to not use --make, to only look at xmonad.hs itself.

Looking at package.confs is something to consider for ghc --make, but 
I strongly feel that's not xmonad job. xmonad.recompile isn't a haskell
package and build system.

Deep recompilation checking would make an interesting extension module,
though. And could be used as leverage on the cabal and ghc --make devs.

I can point you to the relevant trac tickets for recompilation handling,
if you'd like to add more there.

-- Don