This one is a bit tricky. I'll explain it more verbosely.
Usually, all states are sticky. This makes sense, since it means we can easily resume operations without having to re-execute steps that were already executed once (think of cave resume for instance). Re-execution is slow at best and would break things at worst, like unpacking the source tree again after a successful build.
The original description above was bogus. States aren't usually sticky, as far as I can see, it's just that the PretendAction state is only set to failed if a pretend operation fails. The state starts out as non-failed, but having one pretend operation fail means that the PretendAction state can only ever stay on failed.
Unfortunately, this also means that we cannot execute pretend actions for the same package multiple times and correctly check the new state. I'd like to do that, though, in our test suite, for testing different USE flag variations/combinations for USE restrictions.
There are multiple ways to have that working:
reset the pretend action before each visit (done here), which means that pretend actions effectively aren't cached any longer, so it has a very slight performance impact (but since most pretend actions are empty or very lightweight, that shouldn't really matter) which makes sure that it's re-initialized to non-false and shouldn't have bad implications
find a way to clean up a package programmatically before re-executing the pretend action (haven't found an easy way of doing this) manually reset the pretend action state before executing the next pretend action
create n duplicate packages for n different pretend runs. That's ugly, because it blows up the test case code a lot, but it would also work.
I've decided to go with the first method, but the third one would also be viable. It didn't make sense to implement it this way, though.
Keeping this PR open for a bit for others to chime in.
This should be rather safe, so merging directly after all.
This one is a bit tricky. I'll explain it more verbosely.
Usually, all states are sticky. This makes sense, since it means we can easily resume operations without having to re-execute steps that were already executed once (think ofcave resume
for instance). Re-execution is slow at best and would break things at worst, like unpacking the source tree again after a successful build.The original description above was bogus. States aren't usually sticky, as far as I can see, it's just that the
PretendAction
state is only set tofailed
if a pretend operation fails. The state starts out asnon-failed
, but having one pretend operation fail means that thePretendAction
state can only ever stay onfailed
.Unfortunately, this also means that we cannot execute pretend actions for the same package multiple times and correctly check the new state. I'd like to do that, though, in our test suite, for testing different USE flag variations/combinations for USE restrictions.
There are multiple ways to have that working:
which means that pretend actions effectively aren't cached any longer, so it has a very slight performance impact (but since most pretend actions are empty or very lightweight, that shouldn't really matter)which makes sure that it's re-initialized tonon-false
and shouldn't have bad implicationsfind a way to clean up a package programmatically before re-executing the pretend action (haven't found an easy way of doing this)manually reset the pretend action state before executing the next pretend actionn
duplicate packages forn
different pretend runs. That's ugly, because it blows up the test case code a lot, but it would also work.I've decided to go with the first method, but the third one would also be viable. It didn't make sense to implement it this way, though.
Keeping this PR open for a bit for others to chime in.This should be rather safe, so merging directly after all.