Tuesday, February 26, 2013

Shake Links

Summary: Shake is now hosted on GitHub and there is a mailing list.

I've just converted Shake over to Git, hosted on GitHub, and created a mailing list. The full set of Shake related links is now:

  • Download the Haskell package from Hackage and install it using Cabal.
  • Documentation, including examples and a list of all the available functions.
  • Mailing list for any questions/thoughts on Shake.
    • Questions may also be asked on StackOverflow with the tag shake-build-system.
    • Bugs may also be reported on the GitHub issue tracker, but if you aren't sure, use the mailing list.
  • Source code in a git repo, stored at GitHub.

If you want to talk to me about Shake you can now write an email to the mailing list, create a question on StackOverflow, or open a GitHub issue (or still contact me by personal email). I'm available on any means of communication, so pick what suits you best - I'm expecting most users will start with a StackOverflow question if it's a "how do I..." question, or the mailing list if it's more of a discussion/suggestion.

I'm very interested in hearing tales of people who have successfully used Shake, so if Shake works for you, perhaps write it up on a blog, or just send an email to the mailing list. I'm also interested in what doesn't work, what was difficult, what documentation was lacking etc.

Why the sudden Shake activism? Some readers may have noticed a sudden surge in Shake related activity. The reason is that I was reminded of the problems with bad build systems, after using only shake/ghc for many years. I had to work with a team for several hours with a build system written in SCons. The "null build" (with nothing to do) took 38 seconds. The build was structured as three separate SCons build systems, one which compiled a code generator, one which ran the code generator, then another that compiled the result. The build could only run single threaded because it made use of the current directory. A project that was not particularly complex was suffering at the hands of their build system. Some of these are limitations in SCons, some are weaknesses in their use of SCons, but the build system was hindering them, not helping them. I wasted a lot of my time waiting for rebuilds that should have taken seconds. Developers deserve better.

6 comments:

carter t schonwald said...

Awesome! I'm just getting my feet wet with shake, hearing that there'll be more active work on it is exciting!

heisenbug said...

Quick progress report:

Compiling 0.9 with GHC 7.7 (as of 2013-02-20) gives me:


Development/Shake/Oracle.hs:24:10:
Illegal instance declaration for `Rule (OracleQ q) (OracleA a)'
Multiple uses of this instance may be inconsistent
with the functional dependencies of the class.
In the instance declaration for `Rule (OracleQ q) (OracleA a)'
Failed to install shake-0.9
cabal: Error: some packages failed to install:
shake-0.9 failed during the building phase. The exception was:
ExitFailure 1

heisenbug said...

I did some research:

Similar failures were fixed in the test suite:
http://www.haskell.org/pipermail/ghc-devs/2013-January/000042.html

This was the commit that uncovered the problems:
https://github.com/ghc/ghc/commit/fe61599ffebb27924c4beef47b6237542644f3f4

Neil Mitchell said...

heisenebug: Thanks for the report, and for the investigation. Removing the functional dependency on Rules (Development/Shake/Core.hs) should resolve the issue and let you use Shake with 7.7 - the criteria are checked at runtime as well as with the fundep, so won't be harmful. I'm not sure if there is a nicer fix, but sadly there are no Windows snapshots recently, and I've only got a Windows machine to test on at the moment.

heisenbug said...

@neil thanks, it compiles without the fundep (pull request sent).
However it would be nice to salvage the dependency if you think it is semantically relevant. The fundep gods surely know a trick, may be worth asking on the mailing list.

Neil Mitchell said...

@heisenebug, thanks, merged and I also released shake-0.9.1 with the fix.

The fundep isn't so much semantically relevant, as a property I check at runtime that happened to match fundeps, and thus could also be checked at compile time. The fact that fundeps are now more restrictive than my property is no real issue, so I'm happy to leave it out.