On Thu, May 15, 2014 at 05:29:13PM +0200, Bardur Arantsson wrote: > On 2014-05-15 11:35, Magnus Therning wrote: >> On Wed, May 14, 2014 at 10:47 PM, Bardur Arantsson <s...@scientician.net> >> wrote: >>> On 2014-05-12 15:47, Magnus Therning wrote: >>> [--snip--] >>> >>> All I needed to install build-wrapper (which I think was the >>> inital "problem" package in this thread) was to do >>> >>> $ mkdir somewhere/buildwrapper >>> $ cd somewhere/buildwrapper >>> $ cabal sandbox init >>> $ cabal install buildwrapper >>> >>> Add "somewhere/buildwrapper" to $PATH. Bonus points for using >>> "stow" or similar. >>> The key point in the above recipe is to *NOT* have all kinds of >>> libraries installed system-wide (aka. via pacman). It usually >>> works better that way. >> >> Surely you should then `cabal install` the tool so you don't end up >> with a complete sandbox with every dependency of buildwrapper's in >> it, no? > > You *do* need to keep the sandbox around (or at least parts of it). > That's where the last "cabal install" line installs to.
Well, wouldn't you want the binary installed somewhere else, so you don't need to keep the sandbox around? Or do you build all your haskell tools (hlint, hoogle, buildwrapper, hasktags, ghc-mod, etc) in the same sandbox? >> For some packages you would have to keep the sandbox around and do >> it your way though, e.g. `pandoc` since it contains both a library >> and executables. > > If you want to use a sandboxed thing as a library then you need to > develop "inside" the sandbox, so e.g. you'd just create a little > cabal file for your project which declares all the dependencies and > use cabal to build your project. That's indeed the case, but that's *not* the point I was trying to make. If a package only consists of executables you can use the `install` target of the Cabal file to install them. If a package consists of both a library and executables it's more manual work. >>> Disclaimer: I haven't actually used buildwrapper personally, but >>> one assumes that it just acts as an executable and doesn't install >>> things into its own environment or other weird things. >> >> Personally I think `cabal` really shines when doing more serious >> Haskell development than I do. I never test my Haskell packages on >> anything other than the GHC that's in [haskell-core], and neither >> do I test them against any other versions of packages than what's >> found in [haskell-core]. My Haskell development is completely in >> my free time and for fun. I think that if I ever am lucky enough >> find myself using Haskell professionally I'd quickly see more use >> in what `cabal` has to offer. > > Cabal also works beautifully for "hobby" type development. Once > you've created a cabal file you hardly ever need to touch it again. > :) But it's overkill. Do keep in mind that Cabal and `cabal` are two different things. Of course I use Cabal in all my packages, but I don't use `cabal` at all. The main reason I see for using `cabal` would be when I need to maintain compatibility with multiple versions of GHC and or packages I depend on. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus What gets measured, gets done. -- Tom Peters
pgpL8EJJFLR59.pgp
Description: PGP signature
_______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell
