Richard Wallace | 23 Sep 19:43 2012
Picon

Getting started with Shake

Hey all,

I'm going to be working on a webapp in Haskell in the upcoming months
and am thinking Shake would be a good fit - I'll need to do js, css,
and probably some graphics processing as part of the build and would
like to use Shake to automate deployment.

I'm not entirely sure how to get started with Shake.  I've used to
make, jam, maven, sbt and other build tools in the past.  All of these
keep a build configuration in the project and use that to build the
project.  In sbt, which is most like Shake, the build configuration is
written in Scala and compiled by sbt when you run the build.  The
result of the compilation is saved and reused unless it detects that
the build source files changed.

With shake I'm not sure exactly how to get started.  Should I have a
separate project where I create the build system for the webapp?  Or
can I setup something similar to sbt?

Also, how do I handle dependencies with shake?  cabal will pull in
packages from hackage and do the needful, is there anything in shake
to do the same?  If not, how is it normally done?

Thanks,
Rich
Evan Laforge | 24 Sep 17:01 2012
Picon

Re: Getting started with Shake

> With shake I'm not sure exactly how to get started.  Should I have a
> separate project where I create the build system for the webapp?  Or
> can I setup something similar to sbt?
>
> Also, how do I handle dependencies with shake?  cabal will pull in
> packages from hackage and do the needful, is there anything in shake
> to do the same?  If not, how is it normally done?

I have a Shake directory in the project toplevel.  It has Shakefile.hs
and various other utility modules.  A shell script called mkmk
rebuilds the shakefile: 'exec runghc Shake/Shakefile.hs "$ <at> "
build/opt/shakefile', and I usually use 'mk', which is another shell
script: 'exec build/opt/shakefile "$ <at> "'.  You could use runghc all the
time, but I have a large project and interpreting the shakefile is
noticeably slower.

For dependencies I have HsDeps and CcDeps modules which do the minimal
amount of parsing to pull out 'import qualified XYZ' or '#include
"something.h"' lines.  The hs link rule uses it to get the transitive
imports of a binary to 'need' them, and the *.hs.o rule uses it to get
the direct imports of the file it's compiling.  Same story for the
*.cc.o rule and C++ binaries.

There are extra wrinkles for CPP-using hs file and FFI using files
that depend on C wrappers, and multiple build modes (debug, opt,
profile, test) but that's the gist of it.

I don't have a cabal file, just an INSTALL file that I can copy paste
into cabal install.  In the future I'll probably have a cabal file
that doesn't actually compile, just gives deps and their versions, but
(Continue reading)

Rohan Drape | 28 Jan 01:49 2007

Re: getting started with hsc (supercollider)

Hello Alex,

alex <alex <at> slab.org> writes:
| Would anyone have some illustrative example code, and perhaps a
| couple of tips for how to get things working well in emacs?

Noting that Hsc is still experimental and not completely nailed down,
though I think now quite close, and assuming that SuperCollider and
ghc and emacs and the standard haskell emacs mode [1] are all
installed and working, the following should get you started.

* get hsc, or update if you have it (important, recent fixes required)

  darcs get http://slavepianos.org/rd/sw/sw-69

* compile it

  cd sw-69
  runhaskell Setup.hs configure --prefix ~
  runhaskell Setup.hs build
  runhaskell Setup.hs install --user

  (or there is a Makefile to do these three steps...)

* add an appropriately modified variant of the following to ~/.emacs

  (push "/home/rohan/sw/sw-69/emacs" load-path)
  (setq hsc-interpreter "ghci")
  (setq hsc-help-directory "/home/rohan/sw/sw-69/Help/")
  (require 'hsc)
(Continue reading)


Gmane