This doesn't really seem to change anything, but it's more correct and
should reveal weirdness (especially an incorrect .redo directory in a
sub-redo) sooner.
This makes 'redo -j1000' now run successfully in t/curse, except that we
foolishly generate the same files more than once. But at least not more
than once *in parallel*.
Now people waiting for a lock can wait for the fifo to be ready, which means
it's instant instead of polled. Very pretty. Probably doesn't work on
Windows though.
The problem is that redo-ifchange has a different $PWD than its
sub-dependencies, so as it's chasing them down, fixing up the relative paths
totally doesn't work at all.
There's probably a much smarter fix than this, but it's too late at night to
think of it right now.
atoi() was getting redundant, and unfortunately we can't easily load
helpers.py in some places where we'd want to, because it depends on vars.py.
So move it to its own module.
The problem is if someone accidentally creates a file called "test" *before*
.redo/gen^test got created, then 'redo test' would do nothing, because redo
would assume it's a source file instead of a destination, according to djb's
rule. But in this case, we know it's not, since test.do exists, so let's
build it anyway. The problem is related to .PHONY rules in make.
This workaround is kind of cheating, because we can't safely apply that rule
if foo and default.do exist, even though default.do can be used to build
foo.
This probably won't happen very often... except with minimal/do, which
creates these empty files even when it shouldn't. I'm not sure if I should
try to fix that or not, though.
Previously, for testing, we were *always* randomizing the build order of
dependencies. That's annoying since it'll make build logs differ randomly
from one run to the next, which could make comparisons harder. However, the
feature is still useful for uncovering hidden dependencies between objects.
Reading the docs for GNU make more closely, it seems they *don't* use the
one from the environment, because the user's interactive shell preferences
shouldn't affect how the Makefile runs. Good point.
In a Makefile, you can define SHELL explicitly, and that works. But let's
worry about that some other time.
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 that more than one redo doesn't try to build the same thing at the same
time. Kind of dumb, though, since it currently wipes out all the locks at
the toplevel, so running more than one at a time won't give accurate
results, but the -j option doesn't do anything yet.
It used to say:
redo: t/all
redo: hello
and now it says:
redo t/all
redo t/hello
ie. there's no colon, and the path is intact. That means if the build
fails, you can cut-and-paste 'redo t/hello', add a -v, and try to debug
what went wrong.
This is a departure from how djb seems to have it set up, but I just like it
better. It's more like the reasonably-common Makefile standard. (Although
what make *actually* does is just use the first target declared in the
file.)
This is what GNU make does. If SHELL isn't defined, we still fall back to
calling sh.
Rumour has it that Google has some kind of build system that can be
massively distributed if you just set SHELL to the right program; maybe
it'll work with redo now. (Of course it won't do you any good until we
implement parallel builds...)
redo-ifchange already does this, and then calls redo.py, so it's redundant.
The only weird case is if a .do file calls 'redo' instead of
'redo-ifchange'. I'm not sure what exactly is supposed to happen here.
test.do does this, for example, and it works, but only because we always do
'redo test' and nobody depends on 'redo-ifchange test'; if they did, the
dependencies would be off, I guess. But maybe it's meaningless to do that
anyway.
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.
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.
