(One thing beforehand: I'm not saying that any of this _has_
to be done, just that it could be done - somehow...)


Dick Davies wrote:
> * Thomas Bieg <tomsbsd04@tiscali.de> [0114 02:14]:
> 
>>There may be no magic solution for arbitrary packages, but
>>what could be done is to write some tool that "records"
>>the make output beforehand together with some sort of
>>timestamps to get a reference, which could be used (by the
>>same tool) to calculate time estimates during later builds.
> 
> 
> But  as you point out, that makes no odds for new versions.
> And how often do you run exactly the same build twice?

Of course for this to be useful at all, those "reference
files" would have to be integrated into pkgsrc, probably as
part of the regular maintenance process. I'm assuming here
that the package maintainers do at least one compile of every
new package or new version before they commit it (so this
won't be too much extra work if things are automated).


>>If you want a simpler, but *really* imprecise solution
>>you could even have someone pipe the build output through
>>"wc -c" and use the result together with progress(1) for
>>your own build...
> 
> 
> But progress needs to know the length of what ever its monitoring
> to give you a progress indicator. That's not possible in this case.

Sure it is. You measure the output length of the first build
(by output I mean console messages) with wc, like this:

    make | wc -c

Then you get some byte count, say 9999. With that number you
can "progress" your subsequent builds:

    make clean
    make | progress -l 9999 sh -c 'cat >/dev/null'

(I know that this is not very useful for the "real world",
just to show what I mean.)


Regards,
Tom