
Trying to build and run XMonad from within a cabal sandbox using the sandbox feature found in cabal HEAD doesn't manage to build the xmonad binary from xmonad.hs. I belive it's caused by the ghc calls in XMonad.Core. Did anybody else try this? This is how you can see for yourself: * install cabal-install HEAD git clone git://github.com/haskell/cabal.git cd cabal/Cabal ghc --make Setup ./Setup configure --user ./Setup build ./Setup install cd ../cabal-install ./bootstrap.sh * use cabal sandbox for xmonad and XMonadContrib cabal sandbox-init cabal sandbox-configure cabal sandbox-OTHER_COMMANDS (add source, install, etc.) The build output will be in .cabal-sandbox.

On Sat, Feb 9, 2013 at 1:34 PM, Carsten Mattner
Trying to build and run XMonad from within a cabal sandbox using the sandbox feature found in cabal HEAD doesn't manage to build the xmonad binary from xmonad.hs. I belive it's caused by the ghc calls in XMonad.Core.
xmonad is primarily a library with a stub executable; if you built the library in a sandbox, you have very little choice but to run it in that sandbox. I don't see how this is a bug; it certainly cannot be "fixed", unless you expect xmonad to suddenly learn how to track down *at compile time* that it is being built in a sandbox, and either (a) secretly clone a copy of it somewhere else so it will work even when you tear that sandbox down later, or (b) hardcode a reference to that sandbox into the generated xmonad and hope the sandbox is still there when the user goes to build their xmonad.hs. (I encourage you to think about the details here.) -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Sun, Feb 10, 2013 at 1:34 AM, Brandon Allbery
On Sat, Feb 9, 2013 at 1:34 PM, Carsten Mattner
wrote: Trying to build and run XMonad from within a cabal sandbox using the sandbox feature found in cabal HEAD doesn't manage to build the xmonad binary from xmonad.hs. I belive it's caused by the ghc calls in XMonad.Core.
xmonad is primarily a library with a stub executable; if you built the library in a sandbox, you have very little choice but to run it in that sandbox. I don't see how this is a bug; it certainly cannot be "fixed", unless you expect xmonad to suddenly learn how to track down *at compile time* that it is being built in a sandbox, and either (a) secretly clone a copy of it somewhere else so it will work even when you tear that sandbox down later, or (b) hardcode a reference to that sandbox into the generated xmonad and hope the sandbox is still there when the user goes to build their xmonad.hs.
(I encourage you to think about the details here.)
Thanks Brandon I did think about actually and to be precise I did try to build and run it in and from the sandbox.

On Sun, Feb 10, 2013 at 5:12 AM, Carsten Mattner
Thanks Brandon I did think about actually and to be precise I did try to build and run it in and from the sandbox.
Even so, it would need to recognize at compile time that it's in a sandbox and substitute the appropriate cabal-install invocations for ghc. I think this would work better with hsenv, but again even there it would need to recognize that it needs to load hsenv's shell configuration (or you'd need to ensure that xmonad always starts with said configuration, which at least is easier). -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
participants (2)
-
Brandon Allbery
-
Carsten Mattner