apenwarr-redo/t/102-empty/touchtest.do

# This may have been leftover from a previous run, when switching
# between "real" redo and minimal/do, so clean it up.
rm -f touch1

# simply create touch1
echo 'echo hello' >touch1.do
redo touch1
[ -e touch1 ] || exit 55
[ "$(cat touch1)" = "hello" ] || exit 56

# ensure that 'redo touch1' always re-runs touch1.do even if we have
# already built touch1 in this session, and even if touch1 already exists.
echo 'echo hello2' >touch1.do
redo touch1
[ "$(cat touch1)" = "hello2" ] || exit 57

# ensure that touch1 is rebuilt even if it got deleted after the last redo
# inside the same session.  Also ensure that we can produce a zero-byte
# output file explicitly.
rm -f touch1
echo 'touch $3' >touch1.do
redo touch1
[ -e touch1 ] || exit 66
[ -z "$(cat touch1)" ] || exit 67

# Also test that zero bytes of output does not create the file at all, as
# opposed to creating a zero-byte file.
rm -f touch1
echo 'touch touch1-ran' >touch1.do
redo touch1
[ -e touch1 ] && exit 75
[ -e touch1-ran ] || exit 76
rm -f touch1-ran

# Make sure that redo-ifchange *won't* rebuild touch1 if we have already
# built it, even if building it did not produce an output file.
redo-ifchange touch1
[ -e touch1 ] && exit 77
[ -e touch1-ran ] && exit 78

rm -f touch1.do
t/*: some cleanups so switching between redo and minimal/do works. Because the two programs use separate state databases, it helps if we clean up some temp files between runs. Otherwise they might think you created some targets "by hand" and refuse to rebuild them. 2018-10-12 04:18:04 -04:00			`# This may have been leftover from a previous run, when switching`
			`# between "real" redo and minimal/do, so clean it up.`
			`rm -f touch1`

minimal/do: redo vs redo-ifchange, and fix empty target handling. We previously assumed that redo and redo-ifchange are the same in minimal/do's design, because it rebuilds all targets on every run, and so there's no reason to ever build the same target more than once. Unfortunately that's incorrect: if you run 'redo x' from two points in a single run (or even twice in the same .do file), we expect x to be built twice. If you wanted redo to decide whether to build it the second time, you should have used redo-ifchange. t/102-empty/touchtest was trying to test for this. However, a second bug in minimal/do made the test pass anyway. minimal/do would always rebuild any target x that produced no output, not caring whether it had tried to build before, whether you used redo or redo-ifchange. And while we tested that redo would redo a file that had been deleted, we didn't ensure that it would redo a file that was not deleted, nor that redo-ifchange would not redo that file. Fix both bugs in minimal/do, and make t/102-empty/touchtest cover the missing cases. 2018-10-17 01:42:32 -04:00			`# simply create touch1`
$3 and stdout no longer refer to the same file. This is slightly inelegant, as the old style echo foo echo blah chmod a+x $3 doesn't work anymore; the stuff you wrote to stdout didn't end up in $3. You can rewrite it as: exec >$3 echo foo echo blah chmod a+x $3 Anyway, it's better this way, because now we can tell the difference between a zero-length $3 and a nonexistent one. A .do script can thus produce either one and we'll either delete the target or move the empty $3 to replace it, whichever is right. As a bonus, this simplifies our detection of whether you did something weird with overlapping changes to stdout and $3. 2010-12-11 00:29:04 -08:00			`echo 'echo hello' >touch1.do`
			`redo touch1`
			`[ -e touch1 ] \|\| exit 55`
minimal/do: redo vs redo-ifchange, and fix empty target handling. We previously assumed that redo and redo-ifchange are the same in minimal/do's design, because it rebuilds all targets on every run, and so there's no reason to ever build the same target more than once. Unfortunately that's incorrect: if you run 'redo x' from two points in a single run (or even twice in the same .do file), we expect x to be built twice. If you wanted redo to decide whether to build it the second time, you should have used redo-ifchange. t/102-empty/touchtest was trying to test for this. However, a second bug in minimal/do made the test pass anyway. minimal/do would always rebuild any target x that produced no output, not caring whether it had tried to build before, whether you used redo or redo-ifchange. And while we tested that redo would redo a file that had been deleted, we didn't ensure that it would redo a file that was not deleted, nor that redo-ifchange would not redo that file. Fix both bugs in minimal/do, and make t/102-empty/touchtest cover the missing cases. 2018-10-17 01:42:32 -04:00			`[ "$(cat touch1)" = "hello" ] \|\| exit 56`

			`# ensure that 'redo touch1' always re-runs touch1.do even if we have`
			`# already built touch1 in this session, and even if touch1 already exists.`
			`echo 'echo hello2' >touch1.do`
			`redo touch1`
			`[ "$(cat touch1)" = "hello2" ] \|\| exit 57`

			`# ensure that touch1 is rebuilt even if it got deleted after the last redo`
			`# inside the same session. Also ensure that we can produce a zero-byte`
			`# output file explicitly.`
$3 and stdout no longer refer to the same file. This is slightly inelegant, as the old style echo foo echo blah chmod a+x $3 doesn't work anymore; the stuff you wrote to stdout didn't end up in $3. You can rewrite it as: exec >$3 echo foo echo blah chmod a+x $3 Anyway, it's better this way, because now we can tell the difference between a zero-length $3 and a nonexistent one. A .do script can thus produce either one and we'll either delete the target or move the empty $3 to replace it, whichever is right. As a bonus, this simplifies our detection of whether you did something weird with overlapping changes to stdout and $3. 2010-12-11 00:29:04 -08:00			`rm -f touch1`
			`echo 'touch $3' >touch1.do`
			`redo touch1`
			`[ -e touch1 ] \|\| exit 66`
minimal/do: redo vs redo-ifchange, and fix empty target handling. We previously assumed that redo and redo-ifchange are the same in minimal/do's design, because it rebuilds all targets on every run, and so there's no reason to ever build the same target more than once. Unfortunately that's incorrect: if you run 'redo x' from two points in a single run (or even twice in the same .do file), we expect x to be built twice. If you wanted redo to decide whether to build it the second time, you should have used redo-ifchange. t/102-empty/touchtest was trying to test for this. However, a second bug in minimal/do made the test pass anyway. minimal/do would always rebuild any target x that produced no output, not caring whether it had tried to build before, whether you used redo or redo-ifchange. And while we tested that redo would redo a file that had been deleted, we didn't ensure that it would redo a file that was not deleted, nor that redo-ifchange would not redo that file. Fix both bugs in minimal/do, and make t/102-empty/touchtest cover the missing cases. 2018-10-17 01:42:32 -04:00			`[ -z "$(cat touch1)" ] \|\| exit 67`

			`# Also test that zero bytes of output does not create the file at all, as`
			`# opposed to creating a zero-byte file.`
			`rm -f touch1`
			`echo 'touch touch1-ran' >touch1.do`
			`redo touch1`
			`[ -e touch1 ] && exit 75`
			`[ -e touch1-ran ] \|\| exit 76`
			`rm -f touch1-ran`

			`# Make sure that redo-ifchange won't rebuild touch1 if we have already`
			`# built it, even if building it did not produce an output file.`
			`redo-ifchange touch1`
			`[ -e touch1 ] && exit 77`
			`[ -e touch1-ran ] && exit 78`

$3 and stdout no longer refer to the same file. This is slightly inelegant, as the old style echo foo echo blah chmod a+x $3 doesn't work anymore; the stuff you wrote to stdout didn't end up in $3. You can rewrite it as: exec >$3 echo foo echo blah chmod a+x $3 Anyway, it's better this way, because now we can tell the difference between a zero-length $3 and a nonexistent one. A .do script can thus produce either one and we'll either delete the target or move the empty $3 to replace it, whichever is right. As a bonus, this simplifies our detection of whether you did something weird with overlapping changes to stdout and $3. 2010-12-11 00:29:04 -08:00			`rm -f touch1.do`