Re: ALFS shortcomings

On Thu, 20 Sep 2007 16:31:37 -0400, Roger Merchberger
<zmerch-lfs30below.com> 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-discu
ss
FAQ: http://www.linux
fromscratch.org/faq/
Unsubscribe: See the above information page