On Wed, 28 Apr 2004, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
>>> get B that A says it depends on (out of timestamp)
>>> build it
>> against which versions of B's dependencies? dated or latest?
>
> uh, recursion, gosh, didn't think about that. What would you
> suggest?
Avoid recursion. 8-)
We are already in the "HEAD of B doesn't build" branch here. This
means the whole algorithm has already been tried for B before - since
we've already tried to build B before.
When we fall back to a dated B, we should also fall back to dated
dependencies of B IMHO, unless those dependencies are also declared
dependencies of A. So if B depends on C date X and A depends on C
date Y, we should try to build A against B HEAD plus C HEAD and if
that fails against B dated plus C HEAD (and maybe even retract to B
dated plus C Y). If A doesn't explicitly depend on C, use C date X
right away when building against the dated B.
Hmm, maybe the algorithm you describe is tackling the process from the
wrong side. A may have many dependencies, so it should be more of
something like
we want to build A
loop through all dependencies of A - those have been (tried to get)
built already
foreach dependency D
if build has been successful {
add "D HEAD" to the things we will use during build of A
} else {
send mail to A
add "D dated" to the things we will use during build of A
}
}
build A HEAD against the set just collected
if failed {
send mail to A
...
the difficult part in the presence of multiple dependencies
the following is the most simple algorithm that allows us to
build as much as possible without getting lost in combinatorics.
Looks like what Nick suggested.
...
replace all "HEAD" versions in the dependency set with "dated"
rebuild A
if successful {
send mail to A with build results, let A sort out which dependency
to blame
} else {
A's fault, they already have a mail
}
}
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
