Description Michael Rennie 2009-11-30 10:29:38 EST

In its current state our incremental builder performs all of its actions in one shot when the builder is called (as expected). We could however look at breaking the builder up into separate parts, say the compatibility, usage, leak and tag analyzers. The benefit of this would be that we could run each part separately from the others, since each part has different requirements wrt the types it has to scan.

For example:

1. the compatibility analyzer could be run as a Java builder participant, since it only cares about structurally changed types

2. the tag analyzer could also be run as a participant since it only cares about java source that has changed (structurally and non-structurally)

3. The leak and usage parts could be run the way they are now (from the API builder), but we could leverage (record somehow) the changed source file names when the participant runs (from 1 and 2 above), that way we do not have to compute them ourselves, we would only have to look up dependent types whose API description has changed. This would allow us to do less work to know if a leak or usage scan should be a no-op and save us cycles re-doing the same work that the Java builder has already done.