[xmonad] darcs patch: make xmonad recompile if any packages are modified.

[David Roundy]

On Wed, Mar 19, 2008 at 11:11:46AM -0700, Don Stewart wrote:
> droundy:
> > WARNING:  I haven't actually tested this patch.  But it ought to work as
> > advertized, and should give a good start to someone interested in making
> > this work (right now, I don't want to wait half an hour for xmonad-contrib
> > to recompile in order to test it).  Perhaps the cabal folks could also make
> > use of this idea (checking timestamps), so xmonad could segfault less
> > often.  Or we could jury-rig this check into Setup.lhs ourselves...
> > 
> > David
> > 
> > Wed Mar 19 09:37:38 PDT 2008  David Roundy <droundy at darcs.net>
> >   * make xmonad recompile if any packages are modified.
> 
> I'm not going to apply this, but we can use it as more leverage on
> ticket:
> 
>     http://hackage.haskell.org/trac/ghc/ticket/1372

I'm not sure how you think that reproducing this bug in xmonad, such that
fixing it in ghc won't do us any good can really provide us with leverage.
It seems rather to imply that we don't care about the issue.

> See the faq for this issue:
> 
>     http://haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#Help.21_xmonad_just_segfaulted

No, that's not the faq for this issue.  That's the faq for a related issue.

The issue addressed by this bug is

http://haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#Changes_to_the_config_file_ignored

Okay, actually this patch isn't fully adequate to fix this, since ghc may
fail to recompile when we call it (due to the ghc bug you point out).  I
suppose we may need to add an additional bit of code to work around the ghc
bug.  But the patch I submitted has nothing to do with working around ghc
bugs, and only fixes an xmonad bug.

This bug cannot be fixed by any change to ghc --make, since the situation
involves bypassing both those utilities based on our hokey check.
-- 
David Roundy
Department of Physics
Oregon State University