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

34 lines
930 B
Text
Raw Normal View History

minimal/do: don't create a .did file until after a file is actually built. With the new "continue" feature on by default, it turned out that ctrl-c during a build, or a .do file returning an error, would mark a target as "built" even though it hadn't been. This would prevent retrying it when you started minimal/do again. Use a temp file instead. It's a little tricky: to prevent accidental recursion, we want to create a file *before* building, but clean up that file when starting the next session. And we rename that file to the actual .did file *after* building successfully.
2018-11-02 03:48:25 -04:00
rm -f a a.extra b b.ran
Use os.lstat() instead of os.stat(). I think this aligns better with how redo works. Otherwise, if a.do creates a as a symlink, then changes to the symlink's *target* will change a's stat/stamp information without re-running a.do, which looks to redo like you modified a by hand, which causes it to stop running a.do altogether. With this change, modifications to a's target are okay, but they don't trigger any redo dependency changes. If you want that, then a.do should redo-ifchange on its symlink target explicitly.
2018-10-06 00:14:02 -04:00
d0=""
redo a
redo-ifchange b
minimal/do: don't create a .did file until after a file is actually built. With the new "continue" feature on by default, it turned out that ctrl-c during a build, or a .do file returning an error, would mark a target as "built" even though it hadn't been. This would prevent retrying it when you started minimal/do again. Use a temp file instead. It's a little tricky: to prevent accidental recursion, we want to create a file *before* building, but clean up that file when starting the next session. And we rename that file to the actual .did file *after* building successfully.
2018-11-02 03:48:25 -04:00
d1=$(cat b.ran)
Use os.lstat() instead of os.stat(). I think this aligns better with how redo works. Otherwise, if a.do creates a as a symlink, then changes to the symlink's *target* will change a's stat/stamp information without re-running a.do, which looks to redo like you modified a by hand, which causes it to stop running a.do altogether. With this change, modifications to a's target are okay, but they don't trigger any redo dependency changes. If you want that, then a.do should redo-ifchange on its symlink target explicitly.
2018-10-06 00:14:02 -04:00
[ "$d0" != "$d1" ] || exit 11
# b only rebuilds if a changes
../flush-cache
redo-ifchange b
minimal/do: don't create a .did file until after a file is actually built. With the new "continue" feature on by default, it turned out that ctrl-c during a build, or a .do file returning an error, would mark a target as "built" even though it hadn't been. This would prevent retrying it when you started minimal/do again. Use a temp file instead. It's a little tricky: to prevent accidental recursion, we want to create a file *before* building, but clean up that file when starting the next session. And we rename that file to the actual .did file *after* building successfully.
2018-11-02 03:48:25 -04:00
d2=$(cat b.ran)
Use os.lstat() instead of os.stat(). I think this aligns better with how redo works. Otherwise, if a.do creates a as a symlink, then changes to the symlink's *target* will change a's stat/stamp information without re-running a.do, which looks to redo like you modified a by hand, which causes it to stop running a.do altogether. With this change, modifications to a's target are okay, but they don't trigger any redo dependency changes. If you want that, then a.do should redo-ifchange on its symlink target explicitly.
2018-10-06 00:14:02 -04:00
[ "$d1" = "$d2" ] || exit 12
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
. ../skip-if-minimal-do.sh
Use os.lstat() instead of os.stat(). I think this aligns better with how redo works. Otherwise, if a.do creates a as a symlink, then changes to the symlink's *target* will change a's stat/stamp information without re-running a.do, which looks to redo like you modified a by hand, which causes it to stop running a.do altogether. With this change, modifications to a's target are okay, but they don't trigger any redo dependency changes. If you want that, then a.do should redo-ifchange on its symlink target explicitly.
2018-10-06 00:14:02 -04:00
# forcibly changing a should rebuild b.
# a is already symlink to a.extra, but redo shouldn't care about the
# target of symlinks, so it shouldn't freak out that a.extra has changed.
# Anyway, b should still rebuild because a was rebuilt.
../flush-cache
redo a
redo-ifchange b
minimal/do: don't create a .did file until after a file is actually built. With the new "continue" feature on by default, it turned out that ctrl-c during a build, or a .do file returning an error, would mark a target as "built" even though it hadn't been. This would prevent retrying it when you started minimal/do again. Use a temp file instead. It's a little tricky: to prevent accidental recursion, we want to create a file *before* building, but clean up that file when starting the next session. And we rename that file to the actual .did file *after* building successfully.
2018-11-02 03:48:25 -04:00
d3=$(cat b.ran)
Use os.lstat() instead of os.stat(). I think this aligns better with how redo works. Otherwise, if a.do creates a as a symlink, then changes to the symlink's *target* will change a's stat/stamp information without re-running a.do, which looks to redo like you modified a by hand, which causes it to stop running a.do altogether. With this change, modifications to a's target are okay, but they don't trigger any redo dependency changes. If you want that, then a.do should redo-ifchange on its symlink target explicitly.
2018-10-06 00:14:02 -04:00
[ "$d2" != "$d3" ] || exit 13
# Explicitly check that changing a's symlink target (a.extra) does *not*
# trigger a rebuild of b, because b depends on the stamp of the symlink,
# not what the symlink points to. In redo, you declare dependencies on
# specific filenames, not the things they happen to refer to.
../flush-cache
touch a.extra
redo-ifchange b
minimal/do: don't create a .did file until after a file is actually built. With the new "continue" feature on by default, it turned out that ctrl-c during a build, or a .do file returning an error, would mark a target as "built" even though it hadn't been. This would prevent retrying it when you started minimal/do again. Use a temp file instead. It's a little tricky: to prevent accidental recursion, we want to create a file *before* building, but clean up that file when starting the next session. And we rename that file to the actual .did file *after* building successfully.
2018-11-02 03:48:25 -04:00
d4=$(cat b.ran)
Use os.lstat() instead of os.stat(). I think this aligns better with how redo works. Otherwise, if a.do creates a as a symlink, then changes to the symlink's *target* will change a's stat/stamp information without re-running a.do, which looks to redo like you modified a by hand, which causes it to stop running a.do altogether. With this change, modifications to a's target are okay, but they don't trigger any redo dependency changes. If you want that, then a.do should redo-ifchange on its symlink target explicitly.
2018-10-06 00:14:02 -04:00
[ "$d3" = "$d4" ] || exit 14
Reference in a new issue Copy permalink