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

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 "$@" build/opt/shakefile', and I usually use 'mk', which is another shell script: 'exec build/opt/shakefile "$@"'. 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 so far copy pasting a bunch of stuff into cabal install hasn't been a big deal.
participants (2)
-
Evan Laforge
-
Richard Wallace