automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making output of make more beautiful


From: Ralf Wildenhues
Subject: Re: Making output of make more beautiful
Date: Wed, 10 Jun 2009 18:56:26 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hello Paul, Vincent,

* Paul Smith wrote on Wed, Jun 10, 2009 at 02:22:51PM CEST:
> On Wed, 2009-06-10 at 14:04 +0200, Vincent Torri wrote:
> > Is it possible to add 2 features :
> > 
> > 1) adding a percentage at the beginning of the line
> 
> People often ask for this, but it's not possible: a percentage of what?

I'll play devil's advocate on this one.

You can communicate to the toplevel `make' invocation, in the same
manner as the job server, the number of targets considered and the
number of sub-makes invoked.  That won't give you a percentage, of
course, as neither needs to be constant over two `make' invocations
nor with different MAKECMDGOALS.  But these two numbers can give a
rough estimate on the progress.

> > 2) displaying the lines with a color according to what is done 
> > (compilation, execution or error)

> The colorization of different types of rules (rather than output) is
> most easily accomplished by automake, by adding that directly to the
> output.

Yes; and in fact, Automake 1.11 has the option 'color-tests' which can
cause the output of 'make check' to be colorized, if you use the builtin
test driver (i.e., TESTS = ...).

For normal build rules, I would go this way only with another option,
and only if there was a useful and easy semantics for this colorization.

For highlighting compiler warnings, I'd just try out the 'silent-rules'
Automake option (Linux kernel-style build output).

> However, both of these could also be, and are perhaps most easily,
> accomplished via an extra "colorization" tool, where the output of make
> is piped into this tool which reads stdin, colorizes it, then displays
> it.  This saves a lot of effort and change in make and automake and
> provides a clean and much more easily modifiable colorization
> environment.

Of course; and in fact, editors have been doing this task very well for
years already.  But now that we're already on our way to the dark side,
see above, it's even more difficult to convince users that it's the
wrong path.  ;-)

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]