If redo searched all the way up to /default.do, it would run ./default.do instead.
This only happened if the containing project was buggy, ie. you tried to build a target that has no .do file available anywhere. However, it resulted in a confusing outcome for that case, where we'd run the wrong default.do file with the wrong parameters. Extended an existing test to catch this mistake.
This commit is contained in:
parent
90989d1ffb
commit
e5a27f04e8
4 changed files with 18 additions and 4 deletions
|
|
@ -1,7 +1,6 @@
|
|||
rm -f x/shouldfail
|
||||
|
||||
log=$PWD/$1.log
|
||||
rm -f "$log"
|
||||
|
||||
expect_fail() {
|
||||
local rv=$1
|
||||
|
|
@ -15,8 +14,19 @@ expect_fail() {
|
|||
fi
|
||||
}
|
||||
|
||||
# These should all fail because there is no matching .do file.
|
||||
# In previous versions of redo, it would accidentally try to use
|
||||
# $PWD/default.do even for ../path/file, which is incorrect. That
|
||||
# could cause it to return success accidentally.
|
||||
|
||||
rm -f "$log"
|
||||
cd inner
|
||||
expect_fail 11 redo ../x/shouldfail # should fail
|
||||
expect_fail 12 redo-ifchange ../x/shouldfail # should fail again
|
||||
expect_fail 11 redo ../x/shouldfail
|
||||
expect_fail 12 redo-ifchange ../x/shouldfail
|
||||
|
||||
rm -f "$log"
|
||||
cd ../inner2
|
||||
expect_fail 21 redo ../x/shouldfail2
|
||||
expect_fail 22 redo-ifchange ../x/shouldfail2
|
||||
|
||||
exit 0
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue