darcs patch: Separate source and build directories (and 1 more)

2 patches for repository http://code.haskell.org/xmonad: Thu Jun 7 15:16:32 CEST 2012 daniel.trstenjak@gmail.com * Separate source and build directories The source files are still located in '~/.xmonad' and the build files and the xmonad binary are now put into '~/.xmonad_build'. By separating the source and build directories it's easier and nicer to backup and synchronize the source files. Tue Jun 26 20:26:40 CEST 2012 daniel.trstenjak@gmail.com * Add getXMonadDir for backward compatibility

On Tue, Jun 26, 2012 at 9:16 PM,
2 patches for repository http://code.haskell.org/xmonad:
Thu Jun 7 15:16:32 CEST 2012 daniel.trstenjak@gmail.com * Separate source and build directories The source files are still located in '~/.xmonad' and the build files and the xmonad binary are now put into '~/.xmonad_build'.
An alternative location could be ~/.cache/xmonad. yi - possibly via dyre - stores stuff in ~/.cache/yi.
By separating the source and build directories it's easier and nicer to backup and synchronize the source files.
Tue Jun 26 20:26:40 CEST 2012 daniel.trstenjak@gmail.com * Add getXMonadDir for backward compatibility
[Separate source and build directories daniel.trstenjak@gmail.com**20120607131632 Ignore-this: 28d77ca18bd2f05013759b3b50cc1476 The source files are still located in '~/.xmonad' and the build files and the xmonad binary are now put into '~/.xmonad_build'.
By separating the source and build directories it's easier and nicer to backup and synchronize the source files. ] { hunk ./Main.hs 95 buildLaunch :: IO () buildLaunch = do recompile False - dir <- getXMonadDir - args <- getArgs - executeFile (dir ++ "/xmonad-"++arch++"-"++os) False args Nothing + binPath <- getXMonadBinaryPath + args <- getArgs + executeFile binPath False args Nothing return ()
sendRestart :: IO () hunk ./XMonad/Core.hs 28 StateExtension(..), ExtensionClass(..), runX, catchX, userCode, userCodeDef, io, catchIO, installSignalHandlers, uninstallSignalHandlers, withDisplay, withWindowSet, isRoot, runOnWorkspaces, - getAtom, spawn, spawnPID, xfork, getXMonadDir, recompile, trace, whenJust, whenX, - atom_WM_STATE, atom_WM_PROTOCOLS, atom_WM_DELETE_WINDOW, ManageHook, Query(..), runQuery + getAtom, spawn, spawnPID, xfork, getXMonadBinaryPath, getXMonadSourceDir, getXMonadBuildDir, + recompile, trace, whenJust, whenX, atom_WM_STATE, atom_WM_PROTOCOLS, atom_WM_DELETE_WINDOW, ManageHook, Query(..), runQuery ) where
import XMonad.StackSet hiding (modify) hunk ./XMonad/Core.hs 420 modify $ \s -> s { windowset = ws { current = c, visible = v, hidden = h } }
-- | Return the path to @~\/.xmonad@. -getXMonadDir :: MonadIO m => m String -getXMonadDir = io $ getAppUserDataDirectory "xmonad" +getXMonadSourceDir :: MonadIO m => m String +getXMonadSourceDir = io $ getAppUserDataDirectory "xmonad" + +-- | Return the path to @~\/.xmonad_build@. +getXMonadBuildDir :: MonadIO m => m String +getXMonadBuildDir = do + dir <- io $ (++ "_build") <$> getXMonadSourceDir + io $ createDirectoryIfMissing False dir + return dir + +getXMonadBinaryPath :: MonadIO m => m String +getXMonadBinaryPath = io $ (> binName) <$> getXMonadBuildDir + where + binName = "xmonad-" ++ arch ++ "-" ++ os
-- | 'recompile force', recompile @~\/.xmonad\/xmonad.hs@ when any of the -- following apply: hunk ./XMonad/Core.hs 456 -- recompile :: MonadIO m => Bool -> m Bool recompile force = io $ do - dir <- getXMonadDir - let binn = "xmonad-"++arch++"-"++os - bin = dir > binn - base = dir > "xmonad" - err = base ++ ".errors" - src = base ++ ".hs" - lib = dir > "lib" + srcDir <- getXMonadSourceDir + buildDir <- getXMonadBuildDir + binPath <- getXMonadBinaryPath + let err = buildDir > "xmonad" <.> "errors" + src = srcDir > "xmonad" <.> "hs" + lib = srcDir > "lib" libTs <- mapM getModTime . Prelude.filter isSource =<< allFiles lib hunk ./XMonad/Core.hs 463 - srcT <- getModTime src - binT <- getModTime bin + srcT <- getModTime src + binT <- getModTime binPath if force || any (binT <) (srcT : libTs) then do -- temporarily disable SIGCHLD ignoring: hunk ./XMonad/Core.hs 469 uninstallSignalHandlers + let ghcOpts = ["--make", "xmonad.hs", "-i", "-ilib", "-fforce-recomp", "-v0", "-outputdir", buildDir, "-o", binPath] status <- bracket (openFile err WriteMode) hClose $ \h -> hunk ./XMonad/Core.hs 471 - waitForProcess =<< runProcess "ghc" ["--make", "xmonad.hs", "-i", "-ilib", "-fforce-recomp", "-v0", "-o",binn] (Just dir) + waitForProcess =<< runProcess "ghc" ghcOpts (Just srcDir) Nothing Nothing Nothing (Just h)
-- re-enable SIGCHLD: } [Add getXMonadDir for backward compatibility daniel.trstenjak@gmail.com**20120626182640 Ignore-this: 9d83affafd1d8a19285292edca7ccbef ] { hunk ./XMonad/Core.hs 28 StateExtension(..), ExtensionClass(..), runX, catchX, userCode, userCodeDef, io, catchIO, installSignalHandlers, uninstallSignalHandlers, withDisplay, withWindowSet, isRoot, runOnWorkspaces, - getAtom, spawn, spawnPID, xfork, getXMonadBinaryPath, getXMonadSourceDir, getXMonadBuildDir, + getAtom, spawn, spawnPID, xfork, getXMonadBinaryPath, getXMonadSourceDir, getXMonadBuildDir, getXMonadDir, recompile, trace, whenJust, whenX, atom_WM_STATE, atom_WM_PROTOCOLS, atom_WM_DELETE_WINDOW, ManageHook, Query(..), runQuery ) where
hunk ./XMonad/Core.hs 419 $ current ws : visible ws modify $ \s -> s { windowset = ws { current = c, visible = v, hidden = h } }
+getXMonadDir = getXMonadSourceDir + -- | Return the path to @~\/.xmonad@. getXMonadSourceDir :: MonadIO m => m String getXMonadSourceDir = io $ getAppUserDataDirectory "xmonad" }
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

Quoting Carsten Mattner
On Tue, Jun 26, 2012 at 9:16 PM,
wrote: 2 patches for repository http://code.haskell.org/xmonad:
Thu Jun 7 15:16:32 CEST 2012 daniel.trstenjak@gmail.com * Separate source and build directories The source files are still located in '~/.xmonad' and the build files and the xmonad binary are now put into '~/.xmonad_build'.
An alternative location could be ~/.cache/xmonad. yi - possibly via dyre - stores stuff in ~/.cache/yi.
Some links that may be interesting when choosing directory names: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html http://hackage.haskell.org/package/xdg-basedir ~d

An alternative location could be ~/.cache/xmonad. yi - possibly via dyre - stores stuff in ~/.cache/yi.
Yes, I thought about it, but only putting the build files in a freedesktop conforming directory could be perhaps confusing, and I didn't wanted to change the configuration/source directory for backward compatibility reasons. Perhaps having the search order ["~/.config/xmonad", "~/.xmonad"] for configuration/source files could solve that issue. Looking at the 'XDG Base Directory Specification'[1], I don't know if the cache directory is the right one, because of: "... user-specific
non-essential <<< (cached) data should be written."
It's also not that clear what the difference is between $XDG_CACHE_HOME and $XDG_RUNTIME_DIR. There's also $XDG_DATA_HOME, which default value is "~/.local/share", which seems quite strange for user specific data. The XDG seems to be the kind of specification which might create more issues than it solves. [1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

On Wed, Jun 27, 2012 at 9:29 AM, Daniel Trstenjak
An alternative location could be ~/.cache/xmonad. yi - possibly via dyre - stores stuff in ~/.cache/yi.
Yes, I thought about it, but only putting the build files in a freedesktop conforming directory could be perhaps confusing, and I didn't wanted to change the configuration/source directory for backward compatibility reasons.
Perhaps having the search order ["~/.config/xmonad", "~/.xmonad"] for configuration/source files could solve that issue.
Looking at the 'XDG Base Directory Specification'[1], I don't know if the cache directory is the right one, because of: "... user-specific
non-essential <<< (cached) data should be written."
It's also not that clear what the difference is between $XDG_CACHE_HOME and $XDG_RUNTIME_DIR.
There's also $XDG_DATA_HOME, which default value is "~/.local/share", which seems quite strange for user specific data.
The XDG seems to be the kind of specification which might create more issues than it solves.
That's a natural problem when you try to put labels/tags on stuff and sort it into buckets (folders). It's often not so clear.
[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Using either XDG_CACHE_HOME or XDG_RUNTIME_DIR strikes me as preferable over ~/.xmonad_build.

That's a natural problem when you try to put labels/tags on stuff and sort it into buckets (folders). It's often not so clear.
It's just annoying if people try hard to invent new names for stuff which might be already there. What should be the difference between tmp, cache and runtime?
Using either XDG_CACHE_HOME or XDG_RUNTIME_DIR strikes me as preferable over ~/.xmonad_build.
I don't care that much which directory is used. The directory should just have a defined behaviour. I don't think you want to rebuild xmonad on each login, because the build files are deleted on each logout/reboot.

On Wed, Jun 27, 2012 at 10:29 AM, Daniel Trstenjak
That's a natural problem when you try to put labels/tags on stuff and sort it into buckets (folders). It's often not so clear.
It's just annoying if people try hard to invent new names for stuff which might be already there.
What should be the difference between tmp, cache and runtime?
tmp is definitely the wrong choice. It should be either runtime or cache.
Using either XDG_CACHE_HOME or XDG_RUNTIME_DIR strikes me as preferable over ~/.xmonad_build.
I don't care that much which directory is used. The directory should just have a defined behaviour.
I don't think you want to rebuild xmonad on each login, because the build files are deleted on each logout/reboot.
Which directory is defined to be cleared on each login?

Which directory is defined to be cleared on each login?
XDG_RUNTIME_DIR: "The lifetime of the directory MUST be bound to the user being logged in." [1] That's not explicitly demanded for XDG_CACHE_HOME, but some systems might still do it, because of the "non-essential" data part, or put it for performance reasons on a ram disk, like they do with /tmp.
From the specification it's just not that clear what someone can assume and what not.
[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

On Wed, Jun 27, 2012 at 3:01 PM, Daniel Trstenjak
Which directory is defined to be cleared on each login?
XDG_RUNTIME_DIR: "The lifetime of the directory MUST be bound to the user being logged in." [1]
That's not explicitly demanded for XDG_CACHE_HOME, but some systems might still do it, because of the "non-essential" data part, or put it for performance reasons on a ram disk, like they do with /tmp.
From the specification it's just not that clear what someone can assume and what not.
[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
I don't know the thought process when it was written but that sounds a little useless. I don't use GNOME or KDE but haven't yet seen ~/.cache/yi getting wiped. Maybe we should ask Will Donnelly (dyre author) why he chose XDG_CACHE_HOME.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Wed, Jun 27, 2012 at 13:45:30 GMT, Carsten Mattner wrote:
I don't know the thought process when it was written but that sounds a little useless. I don't use GNOME or KDE but haven't yet seen ~/.cache/yi getting wiped.
XDG_RUNTIME_DIR is meant for things like screen or tmux sockets and the like. If $HOME is NFS, putting sockets under it is going to really kill performance. I think XDG_CACHE_HOME is the best spot. I have zsh dump cached completions there. dmenu_run also stores its cache there as well. - --Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJP76qPAAoJEKaxavVX4C1XDJ0QANGlKIcYPUfBf8i60s5qEEKu wokHljFIfqZ/DW0gFiptyO6aWFPNxc8FLsnmGJIZ5tVrdUcVvNPfWO7EtP0YHACi vfB1P/LIda8QvT8wXGGSO/16vyhg9YrfsNx9asc0ogHvYiz0DRsPh8A93hY/zJoa 0R8gJozNu+6KyVeJSSB/9jngpYNZwo4vt97xgJag/tWR0dmRGCkv8oqtzlselPmH bAk54l6ehaV97dQCVCZP7QMzyMLRA7s507ukgIkOscwAphbIVkjhUh0F6ibXJZW/ ZzJjGeKTZiKeixtpjOVsnsB9gZ+Ut9IeQJvvBg188ynYIDmCaGRC8CYwMEwXUDkR 7Nc8gZ2TumvkWuQ9Xnslk2RKbkCDC6CSd82mrK+lyLkUDM/8M2KcGp502SYkvo1s S8paUi/jCNP2I756w19X8w0f6YHARYzYo2O55mrQFBaJiREbl4K3FbKwwX+AiTa0 yBf7jo/ng2RijYiWxAH5aoTa08L9P3y2G8g931sAjGShgbq6Wp/Hervq5ipJ9+dn UHQF9fVTjxcTJADJGrkfzfVKmI6nS7pRG8gPGAFUt4YNtRZfg06bz+ZkSdIkzatz JmvDoA1zv+KnaAkPcCHxzzhoYAWQOTSPQmf+IN3+E2yF4PpIPg3fw+E35NX1fd+v KSDW8Nl/NDsg7ZvDuclm =rbcH -----END PGP SIGNATURE-----
participants (6)
-
Ben Boeckel
-
Carsten Mattner
-
Carsten Mattner
-
Daniel Trstenjak
-
daniel.trstenjak@googlemail.com
-
wagnerdm@seas.upenn.edu