[xmonad] Recompiling on reinstallation

Gwern Branwen gwern0 at gmail.com
Fri May 1 14:49:56 EDT 2009


Don today in #xmonad linked http://braindump.dk/tech/2009/05/01/xmonad-upgrade/

The problem seems to be that the custom xmonad binary was not being
recompiled even when XMonad was upgraded/reinstalled. Fortunately, I
had seen a Yi technique which asked Cabal for the installed binary's
patch; then it could get the last-modified times of the installed
binary & the custom binary, and force a recompile if the former was
newer than the latter.

I coded this up for xmonad-core, but whenever I try it out, I get link
errors. This is not the first time I've seen such errors, so I do not
know whether my patch is flawed or my setup. If anyone wants to try it
themselves and perhaps fix it, I'm attaching it.

The changes:

hunk ./XMonad/Core.hs 55
+import System.FilePath.Posix ((</>))
hunk ./XMonad/Core.hs 60
+import Paths_xmonad (getBinDir)
+
hunk ./XMonad/Core.hs 399
+--      * the installed xmonad executable is more recent than the custom xmonad
+--
hunk ./XMonad/Core.hs 408
---
hunk ./XMonad/Core.hs 411
+    cabalBinDir <- getBinDir
+    let cabalBin = cabalBinDir </> "xmonad"
+    cabalBinT <- getModTime cabalBin
hunk ./XMonad/Core.hs 421
-    if (force || srcT > binT)
+    if (force || srcT > binT || cabalBinT > binT)
hunk ./XMonad/Main.hsc 43
+
+
hunk ./XMonad/Main.hsc 124
-
+    -- have recompile check for a stale custom binary
+    recompile False
hunk ./xmonad.cabal 44
-        build-depends: base < 4 && >=3, containers, directory, process
+        build-depends: base < 4 && >=3, containers, directory,
process, filepath


-- 
gwern
-------------- next part --------------
A non-text attachment was scrubbed...
Name: recompile.dpatch
Type: application/octet-stream
Size: 8624 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/xmonad/attachments/20090501/07c69dcf/recompile-0001.obj


More information about the xmonad mailing list