Jeffrey,
In addition to backwards compatibility, there are other issues to
consider:
1) Granularity: why limit timing data to targets? why not extend it
to tasks as well?
Personally, I'm not interested in timing tasks. Perhaps that could be
debated another time.
2) Filtering: do you want timing data for every target? every task?
As above. I'm interested for this (closing) discussion to consider
target only, not task. Also, this proposal is asking for the a "time
since start of build" not "total time taken for target, start to
finish". Specifically, the time when the target starts, not the time
when the target ends.
and the big one....
3) Multithreading: as the committers on this list will tell you,
I'm always thinking about this one. At IBM, we use Ant + in-house
antlibs to build the WebSphere family of products. We're fortunate
to have very good hardware in our build lab, and with products as
large as WebSphere we're keen on making the most efficient use of
it; one of the ways we do that is to multithread our builds. In our
initial experiments we wanted to get timing data to compare against
our single-threaded builds, so we wrote our own custom logger (just
slight changes to the default logger) to print the timings. When we
ran the builds, everything went haywire.
I see how multithreading would affect a strategy to collect timings.
Again though I'm asking for something else.
---
I think however I I'll let this drop now. There's enough weight of
opinion against the change for it to obviously futile to carry on. No
consensus is emerging.
Have fun,
- Paul
