On Wed, Mar 19, 2008 at 11:00:00AM -0700, Don Stewart wrote:
droundy:
On Wed, Mar 19, 2008 at 11:20:17AM +0100, Joachim Breitner wrote:
Is it possible that having a custom ~/.xmonad/xmonad.hs that wasn't changed across updates could cause xinerama to fail because ~/.xmonad/xmonad-i386-linux doesn't get rebuilt?
Quite possible, happens to me all the time :-)
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.
If in doubt, recompile.
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.
that's a long open ticket for cabal, and I'm not keen to duplicate that for xmonad.
we have a simple policy: look only at xmonad.hs, and compile if it is out of date. that's the only rule. anything else is duplicating --make and chunks of cabal in an ad hoc way.
I disagree. We wouldn't (currently) be duplicating any code in --make or cabal, since both of those don't handle this situation correctly. Moreover, since we don't intend to use either --make or cabal when rebuilding xmonad.hs, it seems reasonable to use a slightly more sophisticated heuristic to remove a pot-hole that many, many users and developers fall into. It is the very unintuitive that every upgrade of xmonad requires a modification of the configuration file in order to take effect. -- David Roundy Department of Physics Oregon State University