The way we're handling them is to have a global timer that is reset at
any point a task is ran.
This gives a maximum amount of chances to any task to have its
dependencies resolve.
A minimum of 60s is given, but in reality the chances are the conditions
for trying to resolve were already present before the timeout started
counting towards that particular dependency.
Note that a long running task, when successfully ran, does not cause the
timeout to be reached.
E.g. at 10s of timeout a task is started, the loop is not executed until
the task exits. When it exits the branch followed is for a task that
ran, which means that even if the task took 70s total (which gives us 80
seconds) a timeout of 60s wouldn't apply here.
Though, please, don't make your tasks take that much time to run!
It looks like this is not a regression from the latest changes to the
kernel builder. Testing on top of ffdba8fecb
exhibits the same issue.
This change works around the issue by doing it with one invocation of
`make`, rather than doing it twice.
It has not been figured out at which exact version of the kernel this
stops being an issue, and if it is an issue from mainline Linux
outright, or something that came from Android-specific modifications.
Though it has been verified that for 3.18, both Qualcomm and Mediatek
source trees exhibit the same issue.
Fixes#216
