This includes a fairly detailed test of various known shell bugs from the
autoconf docs.
The idea here is that if redo works on your system, you should be able to
rely on a *good* shell to run your .do files; you shouldn't have to work
around zillions of bugs like autoconf does.
...only when running under minimal/do, of course.
The tests in question mostly fail because they're testing particular
dependency-related behaviour, and minimal/do doesn't support dependencies,
so naturally it doesn't work.
Now t/curse passes again when parallelized (except for the countall
mismatch, since we haven't fixed the source of that problem yet). At least
it's consistent now.
There's a bunch of stuff rearranged in here, but the actual important
problem was that we were doing unlink() on the lock fifo even if ENXIO,
which meant a reader could connect in between ENXIO and unlink(), and thus
never get notified of the disconnection. This would cause the build to
randomly freeze.
This could be good for distributing with your packages, so that people who
don't have redo installed can at least build it. Also, we could use it for
building redo itself.
Will surely need to get slightly bigger as I inevitably discover I've
forgotten a critical feature.
So if we're in redo/t/ and running 'redo hello', we'll detect redo/.redo and
use that one rather than creating a new redo/t/.redo directory.
The downside of this is we get slightly different behaviour if the *first*
thing you build isn't from the root. Probably that's bad, but it should
hopefully be rare.
'./redo -d test' reveals that we check and re-check things like CC and LD
even when they're children of objects that don't need to be rebuilt, and who
we've already checked earlier in the build cycle. We need to be a little
smarter about pruning if we want dependency checking to be fast.
And move test scripts into t/ subdir to keep things clean.
As part of that, make sure redo adds itself to the PATH on startup so that
subscripts can find it.
