- 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!
5 comments:
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.
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.
Looking forward to your talk, Neil.
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
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.
Post a Comment