On Tue, 2004-02-03 at 19:15, gabriel wrote: > On February 3, 2004 04:43 pm, _JusSx_ wrote: > > if you wonna see progress bars, forget linux and start using windows. > > 'comon. the whole point to linux is to be able to control your own computer. > if this guy wants progress bars (and while some of us may not agree with him, > he's very much *not* alone), he's free to look for community support for such > a move. i'd very much like to see a progress bar, but i just don't see it > being worth the effort at this moment in time. > > but to say "go to windows"... that's just not constructive and just plain > wrong in the longrun. if enough support can be drummed up, we just might see > progress bars in emerge... The problem is largely technical. There is no "set period of time" that it takes to compile something... In fact, it varies widely based upon USE flags. On top of that, it also varies with every version (and every re-version). To acurately gauge a percentange, you would have to calculate the number of files being compiled, the size of those files, how the number and sizes varies with USE flags, CFLAGS, CXXFLAGS and you would have to calculate this for every single version/reversion of the ebuild. And all that is only for programs written in all C/C++. How do you calculate times for packages that are written in mixed languages (ie. C/C++, python, perl, java [is the java app compiled or run with the interpreter?])? As you can see, it is really technically impossible. Even if you made changes to automake (etc...), you'd still have to deal with other languages. My point is this: at this time, it is not technically feasable to offer a semi-accurate progress bar to track the status of per package compile process.
We could however provide a total emerge progress bar based on package size. Basically what this would do is get the size of the package and generate a per package percentage based on the weight of the package size. So if you have 5 packages and the total size of all the downloads is 50 Megs, then 50 Megs would represent 100%. If you broke down the packages like this: 1. 10 Megs - 20% 2. 5 Megs - 10% 3. 5 Megs - 10% 4. 10 Megs - 20% 5. 20 Megs - 40% Then after the first package was merged the progress bar would show 20%, after the second - 30%, the third - 40%, the fourth - 60%, the fifth - 100%. While it is not that accurate (5 megs of rhythmbox would take longer than 20 Megs of ximian-artwork, depending on the system), it could be at least a general idea. What do you think? Nathaniel
signature.asc
Description: This is a digitally signed message part
