Feature request: Emerge Progress

[InfoManiac]

It would be nice to have a progress indicator of some type built into Portage to show progress of:

sanity checks,
package configuration,
gcc compilation status,
progress of all objects being built,
overall progress,
how many packages left to go

As compared to some third party script that someone wrote long time ago, that sort of works but isn't guaranteed to work with portage.

Having this functionality being integrated so that when the status of where everything is at called by a script would be easily obtained.

That way you can know when to go do something else for a while or if things are wrapping up and time to do configs, etc. and return to working with the system.
_________________
GIT-RRRR-DOOOONE!

[Conan]

Its not possible to predict. There are two ways to take a stab at it but both have failings.

[InfoManiac]

Hmmmm.....I wonder if there is a way to possibly make a patch to all make, automake and gcc related packages that would either hack this in or make it so when a call is made portage can split off a separate process, or temporarily pause the current emerge and have it scan where it's at, what's done, what's not, etc.

However you've worked with this much more than I so I haven't any idea how any of this would work, if at all.
_________________
GIT-RRRR-DOOOONE!

[Conan]

Wait--do you want progress of each phase or simply more detailed feedback of which phase things are in? The former is pretty much impossible to get right; the latter already occurs for most phases (xterm title updates)--though it doesn't inform on all phases.

[Dralnu]

If you want something to tell you how long an emerge will take - generally you can get an idea by the size of the download (has been my case, anyways).
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.

[jpmayer87]

Take a look at genlop. it's in portage.

[InfoManiac]

[Dralnu]

[InfoManiac]

Yeah, I am aware of that , but it is the later that you mentioned I was inquiring on.

Is it possible for future builds of Portage to have this, and Mask a certain sub-version number of it until it's ready?
_________________
GIT-RRRR-DOOOONE!

[rane]

Try this:

[smono927]

Hey rane,

Output from "qlop -Cc" doesn't include average build time:

[Genone]

Compilation progress bars have to be implemented in the build system (make, ant, ...), not in portage.

[coolsnowmen]

[steveL]

[smono927]

[BigBrain]

I'd like to have something like a progress bar, too:
Wouldn't it be possible to parse the makefile and count the number of source files that need to be compiled and write after each compiled file how many are left?
This would also be very nice at the configure script!

[steveL]

Hmm someone in #bash who used to run gentoo had a script to do just this, based on source files compiled. We were talking about adding it to update, but the thing is that it would slow your emerge down. Wouldn't an estimate of how long it was going to take, based on prior emerge times (with qlop) be enough? (That in itself is a bit dodgy since it includes emerges which didn't succeed.)

I guess we could look at incorporating lhunath's thing if enough people wanted it, as an option. Personally I wouldn't want to use it.

[Genone]

[BigBrain]

Oh I'm sorry, must have missed that

[Mantaar]

There are build systems that already include progress indicators, but they're not widely used. Back then, when the standard stuff was implemented such functionality wasn't that much of a big concern.

A recent Gentoo Newsletter featured some information on how you can find out the past average build times of certain packages or fetch the information for your processor type via Internet. The results are blurry though:

[Dralnu]

[Mantaar]

Well, it's not all about CPU-time... there's disk IO and other stuff (ooo takes a whole lot of time to actually install.

But measuring the CPU-time instead of real time is probably not a bad idea. I must admit, however, that I don't know enough about the topic to really predict how hard/easy all of this may be...
_________________
Error compiling committee.c: too many arguments to function.

[Genone]

There would be three parts to that:
a) how to measure it? This isn't only about the implementation, but also semantic decisions (like which phases should be measured).
b) how to export it? Existing system uses timestamps in emerge.log to calculate the duration of a build, to export the duration directly you'd have to find another way (without breaking existing tools)
c) adjust tools to use the new system. This should be the easiest part.

[Dralnu]

While disk I/O is a serious part of all this, getting an idea on the time spent in the CPU to try and figure out the time needed to compile would be one thing. Trying to measure the I/O required might be going overboard, since I've got a feeling most of us can, after awhile, figure about how long it would take to copy a file from point A to point B and back, but thats coming from a guy who can give you an idea on how long it will take to compile a program based on downloaded size on his own system.

@Genone:

A) That would be the hard part of it all. I'd probably suggest measuring the time needed to run the ./config script (if there is one, and if this would be reasonably doable), otherwise I'd probably suggest just measuring the whole make proccess itself and call it good.
B) Without knowing alot of the internals, I wouldn't even begin to try and figure that one out. Maybe export is as a count of CPU cycles into emerge.log?
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner.

[steveL]