Wednesday, August 29, 2012

Shake User Feedback

I'll be at ICFP 2012 in a few weeks, talking about Shake. One thing I'd like to include on the slides are some information about how Shake is used by other people. Do you use Shake? If so:

  • What is the project? How do you use Shake?
  • Any comments on Shake, what you like, what you didn't?

Please either leave a comment on the blog, or email me - I'm mainly looking for snippets to put on slides. As always, if you have any other feedback, I'm always interested (this applies to any of my projects).

Shake Updates

Since I'm writing about Shake, I've made a number of enhancements in the darcs repo, which will be included in the next version. These changes include:

  • Faster database serialisation
  • Faster modification time checking
  • GHC 7.6 compatibility
  • Significant improvements to profiling output
  • Improved error messages

Anyone is welcome to try the darcs version out, but I may change the database format again before the final release (causing complete rebuilds), so I don't particularly recommend it - these are all refinements, not rewrites.

I look forward to seeing some Shake users in Copenhagen!
at

5 comments:

  1. Anonymous10:06 PM

    I briefly looked into shake to see if I can use it for latexki (which is a wiki focused on full latex documents, see http://latexki.nomeata.de/ and http://mitschriebwiki.nomeata.de/). I did not continue because it was not clear to me whether shake supports dependency lists that are only known after generating an output.

    An example: I know that foo.tex will generate foo.pdf. If foo.pdf does not exist or is older than foo.tex, then run pdflatex foo.tex. But running that will also gain information on other used files, e.g. bar.sty (by parsing the output, or stracing, or whatever). I’d want to be able to feed this information into the build system and now a modification of bar.sty will also trigger a call to pdflatex foo.tex.

    If this is a supported use case, extending the documentation in that direction would be helpful.

    ReplyDelete
  2. Neil Mitchell10:15 PM

    nomeata: That is most definitely supported - in fact making that easy is one of the main points over make. You can do something like:

    "*.pdf" *> \o -> do
    let tex = replaceExtension o "tex"
    need [tex]
    (stdout,_) <- systemOutput "pdflatex" [tex]
    need $ parseStdoutOfPdfLatex stdout

    Now, provided parseStdoutOfPdfLatex returns the sty/bib files, you have a fully tracked dependency system. The paper (http://community.haskell.org/~ndm/downloads/paper-shake_before_building-10_sep_2012.pdf), sections 2 and 5.1 explain the power of the dependencies, but if you have any suggestions where in the documentation I should have put the information, I'll happily add it.

    ReplyDelete
  3. Andy Gill6:20 AM

    Looking forward to your talk, Neil.

    ReplyDelete
  4. Oliver Batchelor9:47 AM

    Hi Neil,

    I've started using it to build my C++, have enjoyed it quite a bit. There's a bit of scaffolding to get going (sorting out different locations for all the build files for debug vs. release etc.), but the flexibility is really worth it to be able to handle auto-generated files easily.

    Thinking about using it for a bunch of image processing experiments (with lots and lots of images) - so I can make small changes and have only the necessary parts update rather than having to wait forever for a complete run.

    Thanks!
    Oliver

    ReplyDelete
  5. Neil Mitchell6:39 PM

    Andy: I look forward to seeing you there.

    Oliver: Thanks, great comments. I entirely agree with the more setup, but great payoff reasoning - that's why I still recommend things like ghc --make where possible.

    ReplyDelete