forks/apenwarr-redo
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
apenwarr-redo/t/stamp/stamptest.do

58 lines
1.9 KiB
Text
Raw Normal View History

If a checksummed file is deleted, we should still use redo-oob. We were giving up and rebuilding the toplevel object, which did eventually rebuild our checksummed file, but then the file turned out to be identical to what it was before, so that nobody *else* who depended on it ended up getting rebuilt. So the results were indeterminate. Now we treat it as if its dirtiness is unknown, so we build it using redo-oob before building any of its dependencies.
2010-12-11 05:43:02 -08:00
rm -f stampy usestamp usestamp2 stampy.log usestamp.log usestamp2.log
Half-support for using file checksums instead of stamps. A new redo-stamp program takes whatever you give it as stdin and uses it to calculate a checksum for the current target. If that checksum is the same as last time, then we consider the target to be unchanged, and we set checked_runid and stamp, but leave changed_runid alone. That will make future callers of redo-ifchange see this target as unmodified. However, this is only "half" support because by the time we run the .do script that calls redo-stamp, it's too late; the caller is a dependant of the stamped program, which is already being rebuilt, even if redo-stamp turns out to say that this target is unchanged. The other half is coming up.
2010-12-11 02:17:51 -08:00
echo one >inp
../flush-cache.sh
redo stampy
[ "$(wc -l <stampy.log)" -eq 1 ] || exit 11
If a checksummed file is deleted, we should still use redo-oob. We were giving up and rebuilding the toplevel object, which did eventually rebuild our checksummed file, but then the file turned out to be identical to what it was before, so that nobody *else* who depended on it ended up getting rebuilt. So the results were indeterminate. Now we treat it as if its dirtiness is unknown, so we build it using redo-oob before building any of its dependencies.
2010-12-11 05:43:02 -08:00
# stampy already exists, so we won't generate it a second time, even though
# usestamp depends on it.
Half-support for using file checksums instead of stamps. A new redo-stamp program takes whatever you give it as stdin and uses it to calculate a checksum for the current target. If that checksum is the same as last time, then we consider the target to be unchanged, and we set checked_runid and stamp, but leave changed_runid alone. That will make future callers of redo-ifchange see this target as unmodified. However, this is only "half" support because by the time we run the .do script that calls redo-stamp, it's too late; the caller is a dependant of the stamped program, which is already being rebuilt, even if redo-stamp turns out to say that this target is unchanged. The other half is coming up.
2010-12-11 02:17:51 -08:00
redo-ifchange usestamp
[ "$(wc -l <stampy.log)" -eq 1 ] || exit 21
[ "$(wc -l <usestamp.log)" -eq 1 ] || exit 12
../flush-cache.sh
redo stampy
[ "$(wc -l <stampy.log)" -eq 2 ] || exit 31
[ "$(wc -l <usestamp.log)" -eq 1 ] || exit 32
If a checksummed file is deleted, we should still use redo-oob. We were giving up and rebuilding the toplevel object, which did eventually rebuild our checksummed file, but then the file turned out to be identical to what it was before, so that nobody *else* who depended on it ended up getting rebuilt. So the results were indeterminate. Now we treat it as if its dirtiness is unknown, so we build it using redo-oob before building any of its dependencies.
2010-12-11 05:43:02 -08:00
# same as above: stampy is already up-to-date, so it won't be redone.
Half-support for using file checksums instead of stamps. A new redo-stamp program takes whatever you give it as stdin and uses it to calculate a checksum for the current target. If that checksum is the same as last time, then we consider the target to be unchanged, and we set checked_runid and stamp, but leave changed_runid alone. That will make future callers of redo-ifchange see this target as unmodified. However, this is only "half" support because by the time we run the .do script that calls redo-stamp, it's too late; the caller is a dependant of the stamped program, which is already being rebuilt, even if redo-stamp turns out to say that this target is unchanged. The other half is coming up.
2010-12-11 02:17:51 -08:00
redo-ifchange usestamp
[ "$(wc -l <stampy.log)" -eq 2 ] || exit 41
[ "$(wc -l <usestamp.log)" -eq 1 ] || exit 42
If a checksummed file is deleted, we should still use redo-oob. We were giving up and rebuilding the toplevel object, which did eventually rebuild our checksummed file, but then the file turned out to be identical to what it was before, so that nobody *else* who depended on it ended up getting rebuilt. So the results were indeterminate. Now we treat it as if its dirtiness is unknown, so we build it using redo-oob before building any of its dependencies.
2010-12-11 05:43:02 -08:00
# stampy depends on bob, so we'll have to rebuild stampy automatically. But
# stampy's checksum will still be identical.
Correctly handle a checksummed file that depends on a non-checksummed file. We were rebuilding the checksummed file every time because redo-ifchange was incorrectly assuming that a child's changed_runid that's greater than my changed_runid means I'm dirty. But if my checked_runid is >= the child's checked_runid, then I'm clean, because my checksum didn't change. Clear as mud?
2010-12-11 03:29:38 -08:00
../flush-cache.sh
redo bob
redo-ifchange usestamp
[ "$(wc -l <stampy.log)" -eq 3 ] || exit 43
The second half of redo-stamp: out-of-order building. If a depends on b depends on c, and c is dirty but b uses redo-stamp checksums, then 'redo-ifchange a' is indeterminate: we won't know if we need to run a.do unless we first build b, but the script that *normally* runs 'redo-ifchange b' is a.do, and we don't want to run that yet, because we don't know for sure if b is dirty, and we shouldn't build a unless one of its dependencies is dirty. Eek! Luckily, there's a safe solution. If we *know* a is dirty - eg. because a.do or one of its children has definitely changed - then we can just run a.do immediately and there's no problem, even if b is indeterminate, because we were going to run a.do anyhow. If a's dependencies are *not* definitely dirty, and all we have is indeterminate ones like b, then that means a's build process *hasn't changed*, which means its tree of dependencies still includes b, which means we can deduce that if we *did* run a.do, it would end up running b.do. Since we know that anyhow, we can safely just run b.do, which will either b.set_checked() or b.set_changed(). Once that's done, we can re-parse a's dependencies and this time conclusively tell if it needs to be redone or not. Even if it does, b is already up-to-date, so the 'redo-ifchange b' line in a.do will be fast. ...now take all the above and do it recursively to handle nested dependencies, etc, and you're done.
2010-12-11 04:40:05 -08:00
[ "$(wc -l <usestamp.log)" -eq 1 ] || exit 44
Correctly handle a checksummed file that depends on a non-checksummed file. We were rebuilding the checksummed file every time because redo-ifchange was incorrectly assuming that a child's changed_runid that's greater than my changed_runid means I'm dirty. But if my checked_runid is >= the child's checked_runid, then I'm clean, because my checksum didn't change. Clear as mud?
2010-12-11 03:29:38 -08:00
If a checksummed file is deleted, we should still use redo-oob. We were giving up and rebuilding the toplevel object, which did eventually rebuild our checksummed file, but then the file turned out to be identical to what it was before, so that nobody *else* who depended on it ended up getting rebuilt. So the results were indeterminate. Now we treat it as if its dirtiness is unknown, so we build it using redo-oob before building any of its dependencies.
2010-12-11 05:43:02 -08:00
# Make sure the previous step correctly marked stampy and usestamp as up-to-date
# even though *neither* of them is newer than bob.
Correctly handle a checksummed file that depends on a non-checksummed file. We were rebuilding the checksummed file every time because redo-ifchange was incorrectly assuming that a child's changed_runid that's greater than my changed_runid means I'm dirty. But if my checked_runid is >= the child's checked_runid, then I'm clean, because my checksum didn't change. Clear as mud?
2010-12-11 03:29:38 -08:00
../flush-cache.sh
redo-ifchange usestamp
[ "$(wc -l <stampy.log)" -eq 3 ] || exit 45
The second half of redo-stamp: out-of-order building. If a depends on b depends on c, and c is dirty but b uses redo-stamp checksums, then 'redo-ifchange a' is indeterminate: we won't know if we need to run a.do unless we first build b, but the script that *normally* runs 'redo-ifchange b' is a.do, and we don't want to run that yet, because we don't know for sure if b is dirty, and we shouldn't build a unless one of its dependencies is dirty. Eek! Luckily, there's a safe solution. If we *know* a is dirty - eg. because a.do or one of its children has definitely changed - then we can just run a.do immediately and there's no problem, even if b is indeterminate, because we were going to run a.do anyhow. If a's dependencies are *not* definitely dirty, and all we have is indeterminate ones like b, then that means a's build process *hasn't changed*, which means its tree of dependencies still includes b, which means we can deduce that if we *did* run a.do, it would end up running b.do. Since we know that anyhow, we can safely just run b.do, which will either b.set_checked() or b.set_changed(). Once that's done, we can re-parse a's dependencies and this time conclusively tell if it needs to be redone or not. Even if it does, b is already up-to-date, so the 'redo-ifchange b' line in a.do will be fast. ...now take all the above and do it recursively to handle nested dependencies, etc, and you're done.
2010-12-11 04:40:05 -08:00
[ "$(wc -l <usestamp.log)" -eq 1 ] || exit 46
Correctly handle a checksummed file that depends on a non-checksummed file. We were rebuilding the checksummed file every time because redo-ifchange was incorrectly assuming that a child's changed_runid that's greater than my changed_runid means I'm dirty. But if my checked_runid is >= the child's checked_runid, then I'm clean, because my checksum didn't change. Clear as mud?
2010-12-11 03:29:38 -08:00
If a checksummed file is deleted, we should still use redo-oob. We were giving up and rebuilding the toplevel object, which did eventually rebuild our checksummed file, but then the file turned out to be identical to what it was before, so that nobody *else* who depended on it ended up getting rebuilt. So the results were indeterminate. Now we treat it as if its dirtiness is unknown, so we build it using redo-oob before building any of its dependencies.
2010-12-11 05:43:02 -08:00
# now we're changing the contents of stampy.
Half-support for using file checksums instead of stamps. A new redo-stamp program takes whatever you give it as stdin and uses it to calculate a checksum for the current target. If that checksum is the same as last time, then we consider the target to be unchanged, and we set checked_runid and stamp, but leave changed_runid alone. That will make future callers of redo-ifchange see this target as unmodified. However, this is only "half" support because by the time we run the .do script that calls redo-stamp, it's too late; the caller is a dependant of the stamped program, which is already being rebuilt, even if redo-stamp turns out to say that this target is unchanged. The other half is coming up.
2010-12-11 02:17:51 -08:00
../flush-cache.sh
echo two >inp
redo stampy
Correctly handle a checksummed file that depends on a non-checksummed file. We were rebuilding the checksummed file every time because redo-ifchange was incorrectly assuming that a child's changed_runid that's greater than my changed_runid means I'm dirty. But if my checked_runid is >= the child's checked_runid, then I'm clean, because my checksum didn't change. Clear as mud?
2010-12-11 03:29:38 -08:00
[ "$(wc -l <stampy.log)" -eq 4 ] || exit 51
The second half of redo-stamp: out-of-order building. If a depends on b depends on c, and c is dirty but b uses redo-stamp checksums, then 'redo-ifchange a' is indeterminate: we won't know if we need to run a.do unless we first build b, but the script that *normally* runs 'redo-ifchange b' is a.do, and we don't want to run that yet, because we don't know for sure if b is dirty, and we shouldn't build a unless one of its dependencies is dirty. Eek! Luckily, there's a safe solution. If we *know* a is dirty - eg. because a.do or one of its children has definitely changed - then we can just run a.do immediately and there's no problem, even if b is indeterminate, because we were going to run a.do anyhow. If a's dependencies are *not* definitely dirty, and all we have is indeterminate ones like b, then that means a's build process *hasn't changed*, which means its tree of dependencies still includes b, which means we can deduce that if we *did* run a.do, it would end up running b.do. Since we know that anyhow, we can safely just run b.do, which will either b.set_checked() or b.set_changed(). Once that's done, we can re-parse a's dependencies and this time conclusively tell if it needs to be redone or not. Even if it does, b is already up-to-date, so the 'redo-ifchange b' line in a.do will be fast. ...now take all the above and do it recursively to handle nested dependencies, etc, and you're done.
2010-12-11 04:40:05 -08:00
[ "$(wc -l <usestamp.log)" -eq 1 ] || exit 52
Half-support for using file checksums instead of stamps. A new redo-stamp program takes whatever you give it as stdin and uses it to calculate a checksum for the current target. If that checksum is the same as last time, then we consider the target to be unchanged, and we set checked_runid and stamp, but leave changed_runid alone. That will make future callers of redo-ifchange see this target as unmodified. However, this is only "half" support because by the time we run the .do script that calls redo-stamp, it's too late; the caller is a dependant of the stamped program, which is already being rebuilt, even if redo-stamp turns out to say that this target is unchanged. The other half is coming up.
2010-12-11 02:17:51 -08:00
If a checksummed file is deleted, we should still use redo-oob. We were giving up and rebuilding the toplevel object, which did eventually rebuild our checksummed file, but then the file turned out to be identical to what it was before, so that nobody *else* who depended on it ended up getting rebuilt. So the results were indeterminate. Now we treat it as if its dirtiness is unknown, so we build it using redo-oob before building any of its dependencies.
2010-12-11 05:43:02 -08:00
redo-ifchange usestamp usestamp2
Correctly handle a checksummed file that depends on a non-checksummed file. We were rebuilding the checksummed file every time because redo-ifchange was incorrectly assuming that a child's changed_runid that's greater than my changed_runid means I'm dirty. But if my checked_runid is >= the child's checked_runid, then I'm clean, because my checksum didn't change. Clear as mud?
2010-12-11 03:29:38 -08:00
[ "$(wc -l <stampy.log)" -eq 4 ] || exit 61
The second half of redo-stamp: out-of-order building. If a depends on b depends on c, and c is dirty but b uses redo-stamp checksums, then 'redo-ifchange a' is indeterminate: we won't know if we need to run a.do unless we first build b, but the script that *normally* runs 'redo-ifchange b' is a.do, and we don't want to run that yet, because we don't know for sure if b is dirty, and we shouldn't build a unless one of its dependencies is dirty. Eek! Luckily, there's a safe solution. If we *know* a is dirty - eg. because a.do or one of its children has definitely changed - then we can just run a.do immediately and there's no problem, even if b is indeterminate, because we were going to run a.do anyhow. If a's dependencies are *not* definitely dirty, and all we have is indeterminate ones like b, then that means a's build process *hasn't changed*, which means its tree of dependencies still includes b, which means we can deduce that if we *did* run a.do, it would end up running b.do. Since we know that anyhow, we can safely just run b.do, which will either b.set_checked() or b.set_changed(). Once that's done, we can re-parse a's dependencies and this time conclusively tell if it needs to be redone or not. Even if it does, b is already up-to-date, so the 'redo-ifchange b' line in a.do will be fast. ...now take all the above and do it recursively to handle nested dependencies, etc, and you're done.
2010-12-11 04:40:05 -08:00
[ "$(wc -l <usestamp.log)" -eq 2 ] || exit 62
If a checksummed file is deleted, we should still use redo-oob. We were giving up and rebuilding the toplevel object, which did eventually rebuild our checksummed file, but then the file turned out to be identical to what it was before, so that nobody *else* who depended on it ended up getting rebuilt. So the results were indeterminate. Now we treat it as if its dirtiness is unknown, so we build it using redo-oob before building any of its dependencies.
2010-12-11 05:43:02 -08:00
[ "$(wc -l <usestamp2.log)" -eq 1 ] || exit 62
# when we delete the file and it gets regenerated identically, it's as good as
# never having been deleted. So usestamp won't need to change.
../flush-cache.sh
rm -f stampy
redo-ifchange usestamp usestamp2
[ "$(wc -l <stampy.log)" -eq 5 ] || exit 71
[ "$(wc -l <usestamp.log)" -eq 2 ] || exit 72
[ "$(wc -l <usestamp2.log)" -eq 1 ] || exit 73
Reference in a new issue Copy permalink