I kept suspecting Valgrind and kept finding that Valgrind wasn't
actually slowing down Travis CI, but I'd been running it like this:
valgrind ./mu test edit
Which wasn't actually running the underlying ./mu_bin binary atop
Valgrind.
Ok, so Mu is just super slow running any non-trivial apps atop Valgrind.
That's ok, we've rarely needed an app to flush out memory leaks in Mu.
Reorganize build system to minimize duplication while handling 3
scenarios:
1. Locally running tests with `mu test`
2. Locally running tests until some layer with `build_and_test_until`
3. Running on Linux with `test_layers`
4. Running on Travis CI with multiple sharded calls to `test_layers`
One thing we drop at this point is support for OSX in test_layers. We
don't need it now that we have Travis CI working.
2943 almost worked; just a couple of tweaks:
a) Divide up the work a little more finely since we still timed out on
some jobs.
b) Use clang and valgrind when running apps as well.
Kartik Agaram