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

72 lines
2.3 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
Rename flush-cache.py to flush-cache, and rearrange the code a bit. It was working fine, but the style wasn't exactly the way I like it, because I'm unnecessarily picky. :) Also, removed the file extension since we should probably learn from the fact that it's already been rewritten once from one language to another. Who knows, maybe it will be again someday.
2011-02-23 01:24:48 -08:00
../flush-cache
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 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.
Rename flush-cache.py to flush-cache, and rearrange the code a bit. It was working fine, but the style wasn't exactly the way I like it, because I'm unnecessarily picky. :) Also, removed the file extension since we should probably learn from the fact that it's already been rewritten once from one language to another. Who knows, maybe it will be again someday.
2011-02-23 01:24:48 -08:00
../flush-cache
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
Rename flush-cache.py to flush-cache, and rearrange the code a bit. It was working fine, but the style wasn't exactly the way I like it, because I'm unnecessarily picky. :) Also, removed the file extension since we should probably learn from the fact that it's already been rewritten once from one language to another. Who knows, maybe it will be again someday.
2011-02-23 01:24:48 -08:00
../flush-cache
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 stampy
Disable the tests that don't work with minimal/do. ...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.
2010-12-11 20:54:46 -08:00
. ../skip-if-minimal-do.sh
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
[ "$(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.
Rename flush-cache.py to flush-cache, and rearrange the code a bit. It was working fine, but the style wasn't exactly the way I like it, because I'm unnecessarily picky. :) Also, removed the file extension since we should probably learn from the fact that it's already been rewritten once from one language to another. Who knows, maybe it will be again someday.
2011-02-23 01:24:48 -08:00
../flush-cache
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
t/*: update some tests from my rewrite branch. Just some minor test fixes so that tests pass on both current redo and the upcoming rewritten one.
2012-02-07 23:52:54 -05:00
# stampy's checksum will still be identical, so usestamp shouldn't rebuild.
Rename flush-cache.py to flush-cache, and rearrange the code a bit. It was working fine, but the style wasn't exactly the way I like it, because I'm unnecessarily picky. :) Also, removed the file extension since we should probably learn from the fact that it's already been rewritten once from one language to another. Who knows, maybe it will be again someday.
2011-02-23 01:24:48 -08:00
../flush-cache
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
redo bob
t/*: update some tests from my rewrite branch. Just some minor test fixes so that tests pass on both current redo and the upcoming rewritten one.
2012-02-07 23:52:54 -05:00
../flush-cache
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
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
t/*: update some tests from my rewrite branch. Just some minor test fixes so that tests pass on both current redo and the upcoming rewritten one.
2012-02-07 23:52:54 -05:00
# Make sure the previous step correctly marked stampy and usestamp as
# up-to-date even though *neither* of them is newer than bob.
Rename flush-cache.py to flush-cache, and rearrange the code a bit. It was working fine, but the style wasn't exactly the way I like it, because I'm unnecessarily picky. :) Also, removed the file extension since we should probably learn from the fact that it's already been rewritten once from one language to another. Who knows, maybe it will be again someday.
2011-02-23 01:24:48 -08:00
../flush-cache
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
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
t/*: update some tests from my rewrite branch. Just some minor test fixes so that tests pass on both current redo and the upcoming rewritten one.
2012-02-07 23:52:54 -05:00
# now we're changing the contents of stampy. Thus usestamp will need to
# be rebuilt, but not yet...
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 two >inp
t/*: update some tests from my rewrite branch. Just some minor test fixes so that tests pass on both current redo and the upcoming rewritten one.
2012-02-07 23:52:54 -05:00
../flush-cache
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 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
t/*: update some tests from my rewrite branch. Just some minor test fixes so that tests pass on both current redo and the upcoming rewritten one.
2012-02-07 23:52:54 -05:00
# let's see about usestamp. It needs to be rebuilt because stampy has changed,
# but since stampy is *already* changed, stampy itself shouldn't be re-rebuilt.
../flush-cache
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.
Rename flush-cache.py to flush-cache, and rearrange the code a bit. It was working fine, but the style wasn't exactly the way I like it, because I'm unnecessarily picky. :) Also, removed the file extension since we should probably learn from the fact that it's already been rewritten once from one language to another. Who knows, maybe it will be again someday.
2011-02-23 01:24:48 -08:00
../flush-cache
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
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
Fix a deadlock with redo-oob. If a checksummed target A used to exist but is now missing, and we tried to redo-ifchange that exact file, we would unnecessarily run 'redo-oob A A'; that is, we have to build A in order to determine if A needs to be built. The sub-targets of redo-oob aren't run with REDO_UNLOCKED, so this would deadlock instantly. Add an assertion to redo-oob to ensure we never try to redo-ifchange the primary target (thus converting the deadlock into an exception). And skip doing redo-oob when the target is already the same as the thing we have to check.
2010-12-11 06:16:32 -08:00
# this simple test used to cause a deadlock.
Rename flush-cache.py to flush-cache, and rearrange the code a bit. It was working fine, but the style wasn't exactly the way I like it, because I'm unnecessarily picky. :) Also, removed the file extension since we should probably learn from the fact that it's already been rewritten once from one language to another. Who knows, maybe it will be again someday.
2011-02-23 01:24:48 -08:00
../flush-cache
Fix a deadlock with redo-oob. If a checksummed target A used to exist but is now missing, and we tried to redo-ifchange that exact file, we would unnecessarily run 'redo-oob A A'; that is, we have to build A in order to determine if A needs to be built. The sub-targets of redo-oob aren't run with REDO_UNLOCKED, so this would deadlock instantly. Add an assertion to redo-oob to ensure we never try to redo-ifchange the primary target (thus converting the deadlock into an exception). And skip doing redo-oob when the target is already the same as the thing we have to check.
2010-12-11 06:16:32 -08:00
rm -f stampy
redo-ifchange stampy
[ "$(wc -l <stampy.log)" -eq 6 ] || exit 74
Reference in a new issue Copy permalink