Re: colorful make output! yum!

[Phil Holmes]

----- Original Message ----- 
From: "Janek Warchol" <address@hidden>
To: "David Kastrup" <address@hidden>
Cc: "Thomas Morley" <address@hidden>; "LilyPond Developmet Team" 
<address@hidden>
Sent: Monday, August 19, 2013 8:33 PM
Subject: Re: colorful make output! yum!


> Hi,
>
> 2013/8/15 David Kastrup <address@hidden>:
> > Franciszek Boehlke <address@hidden> writes:
> >
> > > I think I can promise to support and maintain it.
> >
> > If we have a subsystem depend on continued support by a single person,
> > it must be easy to remove the subsystem as a whole.
> >
> > Consider it LilyPond's life insurance.  We don't really want such
> > dependencies.  They mean that if one person quits, it will take at least
> > five times the original effort to maintain stuff.  "Don't look here,
> > somebody else will maintain it" corners are really expensive in the long
> > run.
>
> could you explain how this patch could become difficult to maintain
> and/or cause building problems?
> I've read the patch and despite the fact that i don't know anything
> about make and makefiles, i quite clearly undestand what it's doing,
> and that it's very straightforward.  I don't see how it could cause us
> trouble.
>
> Btw, Franek, Harm tried compiling lilypond with your patch and the
> colors didn't show - there were just verbatim color codes.
> Interestinglty, git log and diff worked with colors.  Any ideas?
>
> best,
> Janek
>
> PS i don't consider the above bug with color codes a serious problem
> (but maybe i'm wrong?): lilypond builds as usual,  and make output is
> still more readable than before.

I've had a look, and have a few problems with this approach. The first,
simple, one is that it doesn't generate any colours on my vanilla Ubuntu
installation, so all the control codes are clutter at this stage. So, for
me, on my system, it adds no value. Second: it puts all the control
characters in the logfile if you run "make &> make.log". That's not what
you want. The logfile should be the output from make alone, not other
commentary - once you learn to understand the output of make to understand
why a build has failed, other output gets in the way. Third: The real
benefit of my work on make doc was _reducing_ the amount of screen clutter,
so that if the build did fail, we could work out why quite quickly, instead
of having to wade through 50,000 lines of output. Trying to make the output
"prettier" should not be the aim. Fourth: 99% of the time, the output of
make is irrelevant - you shouldn't be trying to watch what's happening.
Graham was always of the view that you should type "make" and go and make a
coffee. On my fast machine, I type make, see 100s of lines scroll past too
fast to read, and 8 seconds later can see my new glyphs. Having that rapid
scrolling in colour would probably give me a headache.

I'm sure Franek learnt a lot about the build system from this exercise, and
it was therefore valuable. However, I (and, from what I've seen, David K, 
and
almost certainly Graham and probably Julien) would strongly oppose adding
extra complexity to the already over-complex build system.


--
Phil Holmes