I would like a version of the Unix 'make' utility that (in addition to, or instead of, the usual command/output chatter) displays a progress meter showing the percentage of the build finished and the estimated time to completion.
This would be particularly useful when building large projects (such as the Linux kernel). Sure, a quad-processor gigahertz Athlon can probably build the whole thing in a few seconds, but some of us have to wait a while for our lesser hardware to crunch through the process.
File-by-file variations in compile times and recursive invocations of 'make' and other tools may make this more difficult, but surely these problems could be solved. (Recursive make is harmful anyway!)
(Perhaps the right answer is a universal progress meter that watches the output from any command, and learns over time how to recognize progress?)-- egnor, Aug 11 2000 If this involves a complete re-design and re-write of make, then i'm all for it!
(i'll spare you my rant on make.)
You're right, the recursive nature of make is the main obstacle with this idea. The top level makefile has no idea how many makefiles exist underneath it.
In general, an accurate progress bar (i.e. a one based on time) is a rare occurance. I'm not sure if it is that difficult to do, but i expect it is just programmer laziness. Every windows installer I've ever seen counts the numbers of operations, not the time it takes to complete an operation.
So, a installing a 4 meg file and a 4 byte file are considered equal.
I think we need a progress meter design pattern that considers time, not just number of operations.
Combined with your universal progress meter that times all commands and i think you've got something pretty tasty.-- ufreq, Sep 28 2000 I was chosen to implement a time wise progress bar, and it is exceedingly difficult to get it to any level of accuracy. The best I came up with was to take ten samples of time for say 10 ops, skip 100, then take ten samples. Taking the average time for the most recent ten samples, I subtracted the average time from the older ten samples. This gave me an idea of performance improvement or degradation over time. Since I knew how many records I had to process (I'm calling them ops to keep the language as simples as possible) I could figure out what the ultimate improvement in time would be for the final records, and apply the gradual change to the records in between. These samples were done repeatedly as processing continued. It was accurate to within a minute for a two hour project, so I was pretty pleased with the result.
Unfortunately, the interceptor missed the incoming missle by 36 seconds, and it blew Harfy Island (off South Carolina) into several small bits. We said it was an earthquake. :)-- pnewp, Feb 07 2001 Yes, yes, yes! Even a proportion of files done bar, rather than a time bar, would be useful.
"Wasted time..." -- Dishwalla-- beland, Feb 07 2001 That universal progress meter sounds *very* useful. How would it be done? Surely to comply with it and give it something to work with, programs would have to feed it huge amounts of information - in a fairly generic format.
I see no excuse why recursive processes like make shouldn't have useful information - it just needs to bother looking in advance and adding the files up.-- sadie, Apr 22 2002 Imagine no longer. The Eclipse 3.0m7 IDE display a build progress meter for Java projects.
However, as Eclipse compiles each file after each file save, you only need this progress meter when Eclipse opens the project the very first time(!).
Download Eclipse from <http://www.eclipse.org/>-- thor574, Apr 16 2004 random, halfbakery