Subject: Re: pkgsrc progress bar?
To: Thomas Bieg <email@example.com>
From: Richard Rauch <firstname.lastname@example.org>
Date: 01/20/2005 00:00:53
I think that you still have problems, Thomas. The amount of
output from "make" will depend on:
* Have you partially built it already?
* What other packages are there that are part
of the task? (Usually it's a tree of dependencies
that take most of the time...)
* /etc/mk.conf and environment options.
* Platform-specific tailoring.
Perhaps, though, if you could see some kind of running status,
which might be deduced by writing formatted log lines and
sending each build's output to a (separate?) file. Then
seeing something like:
Foo Bar Quxx
(bar) (fetching) (done)
...maybe laid out in a tree fashion:
+--- Baz (already installed)
+--- Quxx (done)
| +--- Bar (fetching)
+--- Bar (Foo)
"current" is building.
"Baz" was built before we started buiding "current".
"Quxx" was built for "current" and is now done.
"Foo" is building.
"Bar" is being built by "Foo" and is fetching distfiles.
"Bar" is also directly requird by "current", but will be
built by dependency "Foo" before "current" gets around
...now, without adding extra stuff to the system, it may be non-trivial
to support that. But it certainly is *possible*, and (IMHO) would provide
some useful status information.
Another possible source of info is to cache how long it took to build a
package *on*this*system* as part of /var/db/pkg (provide a tool to zero
the information out in case the hard drive migrates; (^&). This estimate
would have to exclude fetch time to be very meaningful, and should not
include the time to build dependencies.
That I think would be useful. I often *do* build a given package
more than once (or almost exactly the same package) owing to
dependency packages being updated, and/or a given package having
a very minor security patch applied (minor in terms of compilation
time, anyway; (^&).
...no, I'm not volunteering to do it. While it sounds cool, it doesn't
really matter too much to me. But I think that it could be done in a way
that produces information that is at least as useful as, say, the
system load average. (^&
"I probably don't know what I'm talking about." http://www.olib.org/~rkr/