Re: Feature request: output idea

[Mike Gibson]

On Wednesday 27 August 2003 05:28 am, Noel Yap wrote:
> Full Decent wrote:
>
> Since this isn't a bug, I'm replying to address@hidden
>
> > I think it would be amazing if there was an optional output mode for
> > make that would simply have a console (curses) progress bar with the
> > name of the target and the status of its "compilation" like:
> >
> > bzImage         [==================================] 100%
> > modules         [==================================] 100%
> > modules_install [=============>                    ]  40%
>
> This would be a neat feature.
>
> > Is something like this possible? Do you think it would be very difficult
> > for me to make a submit a patch for something like this?
>
> Anyone is always welcome to try to create and submit patches.
>
> OTOH, I don't know how you'd go about creating this feature.  For example,
> make has little or no communication with the compiler or linker.  Even if
> it did, these tools typically don't advertise how much more work they have
> -- I'm not even sure if it's possible for them to know how much more work
> they have.  And compiles and links are the simple cases.
>
> What about targets whose actions are completely custom?

If you look at his example (from a linux kernel compile), it might give a nice 
clue to what might work, even if the origninal poster might not have realized 
it.  While it is true that you're not going to be able to retrieve a "% 
complete" from individual invocations of rules, when a target (like modules) 
has a *lot* of prerequisites (like in a kernel compile), then it makes sense 
to give a "% complete" based on the number of prerequisites that have been 
built.

It would certainly clean up the otherwise useless output (lots of gcc 
invocations in the case of a kernel compile) of some builds and give 
something useful.

Some dificulties that I can think of off the top of my head are error 
reporting.  Currently, all output goes to stdout, but if you wanted progress 
bars, then that output would have to be suppressed.  But if an error occured, 
then the output of errors that the user would normally want to see would be 
lost to /dev/null.

However, I don't see why it couldn't be implemented without breaking anything.

Mike Gibson