Nathaniel McCallum wrote:
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.
A bit bloated solution I had in mind once was to create a stubmake
program that would walk through the make process, but instead of
actually executing the compiler commands it would count them for the
progress bar to use, and because it'd simulate typical make process it
would always know the exact amount of commands the make process would
execute in the current specific settings. Of course this kind of
progress bar wouldn't be time-exact but in typical case it would show
rather good estimates. Even more so if there was some added estimations
in the progress bar ("linking of 100 files takes longer time than
compiling one, let's give it 10%..." and so on).
--
.signature: No such file or directory
