On 2014-05-15 23:18, Magnus Therning wrote: > 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? >
What I do for executable-only is pretty simple. I use stow to manage all non-distro software that I install, so I have one directory per package, like so: ~/stow/ghc-mod/lib/ghc-mod/src ~/stow/hums/lib/hums/src (etc.) Each of these directories contains a full sandbox with a locally-run "cabal install". For each package I add a "bin" directory, so ~/stow/ghc-mod/bin and put in the necessary relative symlinks: ~/stow/ghc-mod-4.0.2/bin cpphs -> ../lib/ghc-mod/.cabal-sandbox/bin/cpphs ghc-mod -> ../lib/ghc-mod/.cabal-sandbox/bin/ghc-mod ghc-modi -> ../lib/ghc-mod/.cabal-sandbox/bin/ghc-modi hlint -> ../lib/ghc-mod/.cabal-sandbox/bin/hlint HsColour -> ../lib/ghc-mod/.cabal-sandbox/bin/HsColour And finally use stow to "merge" the package into my ~ directory, so that all the bin/ symlinks end up in my ~/bin. (I use stow because I'm pretty pendantic about keeping "packages" separate from everything else in my $HOME, but you could also just have a ~/src with a sandbox for every package and add symlinks directly from your ~/bin into the sandboxes. It's just that since all my non-haskell non-distro self-built software is managed by stow, I chose to also use stow for this.) >>> 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. I think we might be talking past each other... I'm afraid I don't understand what you mean by "more manual work". Using sandboxes the way I've described above doesn't really work at all for executable + library situations. (So I offered a different solution to that problem, namely cabal-ifying your own package that depends on a library and installing your own package in a sandbox.) >> 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. > If we want to get pendantic, it's probably best to say Cabal vs. cabal-install (which is where the "cabal" executable comes from, for those who don't know). I use cabal-install for all development with a .cabal file for each of my projects, I never use Cabal (the library) directly as I've never encountered a need to. I've not encountered many packages which use anything other than the standard boilerplate Setup.hs/Setup.lhs file. (Some packages with *really* complex build requirements do so, e.g. Gtk2hs, but I assumed that's not quite the level of complexity we're talking here.) Anyway, enough rambling on... Regards, _______________________________________________ arch-haskell mailing list arch-haskell@haskell.org http://www.haskell.org/mailman/listinfo/arch-haskell