| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
More tweaking; edit/ still taking too long to test on Travis CI.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
I'm already using grep and perl, bash is no worse, and it's *much* nicer
to work in than plain Bourne sh.
|
|
|
It easily exceeded the 50-minute timeout.
|