On Thu, 20 Sep 2007 16:31:37 -0400, Roger Merchberger <[EMAIL PROTECTED]> wrote:
> For larger processes with many steps / commands... say 20, issue each step > a 5% complete status, and update the bar at each step... Ah yes..."There are three kinds of lies: lies, damned lies and statistics" :-) For most LFS packages, there are only 3-4 steps: configure, make, make check, make install > If it was a long process with only a few steps, if the application had > access to the process logging, one could tee & grep the logs & when > certain > "milestones" were reached one could update the progress bar. Unfortunately, this is unlikely to be accurate either - in it's most simple implementation, things like autoconf/automake will reach 50% very quickly, then take a disproportionate amount of time to hit 75% due to the relatively long time their test suites take and quickly hit 100% as the install target is pretty minimal. Processing log files would get around this - assuming you could watch for particular make targets or tests being run. However, this requires an incredible amount of effort, and such log-progress mappings would need to be reviewed/updated on each new upstream release of the package that makes it into the book. Unless, of course, I'm missing something. > Again, this is just academic blathering... ;-) As is this :-) > [1] Please note: if I had a boss that told me that, I'd still ask him if it > was worth that much work for what little (any?) benefit... Yep, quite often all that is required is to keep on asking him "what is it you want to achieve"? In this case, what I would want is something that can tell me two things: 1) Is the package build process still running/has it hung somewhere and 2) How long is it likely to take to build/finish building. 1) jhalfs already produces log files, so just tailing these is sufficient for my needs. If it looks like it's hung, I just use 'ps' to confirm. I'm not sure jhalfs needs to do anything more for this case. 2) Maybe jhalfs could display a) SBU time b) how many SBUs the current package is estimated to take (and therefore also the estimated time by doing the simple a*b calculation) and c) how long the package has taken to build so far. If updating c) is just as expensive as updating the current progress bar, simply outputting the time the package build started would be sufficient and I could do the rough math myself. Regards, Matt -- http://linuxfromscratch.org/mailman/listinfo/alfs-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
