Nondeterministic build order makes fixing heavily broken projects painful

[copumpkin]

Here's my scenario:

1. Get a project that doesn't build for several different reasons
2. Run xcbuild
3. Watch it fail for reason A
4. Try to fix A
5. Rerun xcbuild
6. Watch it fail for reason B
7. Weep because you don't know if it's failing for reason B because your fix for A was successful, or because xcbuild just decided to do B before trying A, and A is actually still broken.

Not sure if this is caused by parallelism or something else, but it's kind of painful right now.

[matthewbauer]

This might be fixed by switching from the simple executor to the Ninja executor.

Another issue with the simple executor is that it will print errors in the middle of other build output.

[grp]

Agree this is painful. One tip might be to pass in -target <name> to only build the target you're working on until that gives no results.

[copumpkin]

@matthewbauer yeah I've been seeing the interleaved error messages a lot. Perhaps difference in flushing policy between stderr and stdout?

@grp yeah, unfortunately even within a target I have multiple distinct errors. I wasn't kidding when I said this thing was broken 😄

[grp]

Ah. :D With Ninja you can make it rebuild a specific file by running Ninja directly with the output .o as the target to build. Might help?

[onhachoe]

At least the interleaved output should be fixed with #240