[prev in list] [next in list] [prev in thread] [next in thread]
List: lilypond-devel
Subject: Re: colorful make output! yum!
From: Franciszek Boehlke <franio.kropka.b () gmail ! com>
Date: 2013-08-27 20:09:18
Message-ID: CAJGPRQrUOG_bazgBC=LZpXf-zeBhkfA4hqDTxr6rvGNnQtWiUw () mail ! gmail ! com
[Download RAW message or body]
Hi,
thank you for all your feedback.
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?
>
It may be problem with echo invocation, and option -e (interpreting
backslash escapes) not working properly. Possibly replacing "env echo" with
"/bin/echo" or something similar in make/stepmake.make may help.
Pardon me for butting in, but is maintaining this feature better than
> maintaining a config file for colortail?
>
I believe colortail is not really suitable for that task, and maintaining
it's config file would be much more expensive. I mean, if the point was to
make output colorful, colortail could fit well, but my idea is to replace
make output with something shorter and more human-friendly. Colors are only
part of this patch, and not most important.
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.
The output should be much shorter, and, if you omit control codes (i'm
going to fix them), more readable.
Second: it puts all the control
> characters in the logfile if you run "make &> make.log". That's not what
> you want.
Will be fixed.
> 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.
>
So that was my point, too. I added colors to make it even easier to see
what happened
- by making direct make output (i.e. description of commands) easy to
distinguish from output of these
commands, e.g. g++.
> 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.
>
So you should see at most few tens of lines, if you are going to compile
only glyphs
(plus some more lines like "make[1]: Entering directory `/foo/bar`" or
"make[2]: Leaving directory `/foo/baz`; I'm not sure, if it's possible to
hide them).
I'm completely convinced they ain't going to give you a headache.
Short summary (with some additions):
Main point of this patch, despite it's name, is not making make output
prietter and colorful,
but making it shorter and more readable. My inspiration was output of
cmake, which I find
really nice. To achieve this, I've hidden (almost) all commands from make
output, and replaced
them with easily understandable descriptions. Then i make them colorful, to
differentiate them
from other parts of output (e.g. g++ output). Last thing was to make hiding
metafont output
the default behavior (it used to be an option). Metafont was responsible
for majority of output
mess in complete compilation, as it's log is very long, and completely
useless for most of contributors.
I'm going to make this patch easy to disable by options, and fix some
issues, but it will take some time
- i'm quite busy now. I'll try to continue it in about 2-3 weeks.
Greetings,
Franek
[Attachment #3 (text/html)]
<div dir="ltr">Hi,<br>thank you for all your feedback.<br><br><blockquote \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div> Btw, Franek, Harm tried \
compiling lilypond with your patch and the<br> colors didn't show - there were \
just verbatim color codes.<br> Interestinglty, git log and diff worked with colors. \
Any ideas?<br></div></blockquote><div><br></div><div>It may be problem with echo \
invocation, and option -e (interpreting backslash escapes) not working properly. \
Possibly replacing "env echo" with "/bin/echo" or something \
similar in make/stepmake.make may help.<br>
<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex" class="gmail_quote"> Pardon me for butting in, but \
is maintaining this feature better than maintaining a config file for \
colortail?<br></blockquote><div><br></div><div>I believe colortail is not really \
suitable for that task, and maintaining it's config file would be much more \
expensive. I mean, if the point was to make output colorful, colortail could fit \
well, but my idea is to replace make output with something shorter and more \
human-friendly. Colors are only part of this patch, and not most important.<br>
<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex" class="gmail_quote">I've had a look, and have \
a few problems with this approach. The first,<br> simple, one is that it doesn't \
generate any colours on my vanilla Ubuntu<br> installation, so all the control codes \
are clutter at this stage. So, for<br> me, on my system, it adds no \
value.</blockquote><div><br>The output should be much shorter, and, if you omit \
control codes (i'm going to fix them), more readable.<br><br></div><blockquote \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex" class="gmail_quote">
Second: it puts all the control<br>
characters in the logfile if you run "make &> make.log". That's \
not what<br> you want. </blockquote><div>Will be fixed.<br></div><div> \
</div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex" class="gmail_quote">The logfile should be the \
output from make alone, not other<br>
commentary - once you learn to understand the output of make to understand<br>
why a build has failed, other output gets in the way. Third: The real<br>
benefit of my work on make doc was _reducing_ the amount of screen clutter,<br>
so that if the build did fail, we could work out why quite quickly, instead<br>
of having to wade through 50,000 lines of output. Trying to make the output<br>
"prettier" should not be the aim. Fourth: 99% of the time, the output \
of<br> make is irrelevant - you shouldn't be trying to watch what's \
happening.<br></blockquote><div>So that was my point, too. I added colors to make it \
even easier to see what happened<br> - by making direct make output (i.e. \
description of commands) easy to <span \
style="color:rgb(0,0,0)">distinguish<span></span></span> from output of these<br>
commands, e.g. g++.<br> <br></div><blockquote style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"> \
Graham was always of the view that you should type "make" and go and make \
a<br> coffee. On my fast machine, I type make, see 100s of lines scroll past too<br>
fast to read, and 8 seconds later can see my new glyphs. Having that rapid<br>
scrolling in colour would probably give me a headache.<br></blockquote><div>So you \
should see at most few tens of lines, if you are going to compile only glyphs \
<br>(plus some more lines like "make[1]: Entering directory `/foo/bar`" or \
<br>
"make[2]: Leaving directory `/foo/baz`; I'm not sure, if it's possible \
to hide them).<br>I'm completely convinced they ain't going to give you a \
headache.<br><br><br></div><div>Short summary (with some additions):<br>
</div><div>Main point of this patch, despite it's name, is not making make output \
prietter and colorful,<br>but making it shorter and more readable. My inspiration was \
output of cmake, which I find<br>really nice. To achieve this, I've hidden \
(almost) all commands from make output, and replaced<br>
them with easily understandable descriptions. Then i make them colorful, to \
differentiate them<br>from other parts of output (e.g. g++ output). Last thing was to \
make hiding metafont output<br>the default behavior (it used to be an option). \
Metafont was responsible for majority of output<br>
mess in complete compilation, as it's log is very long, and completely useless \
for most of contributors.<br><br></div><div>I'm going to make this patch easy to \
disable by options, and fix some issues, but it will take some time<br>
- i'm quite busy now. I'll try to continue it in about 2-3 \
weeks.<br><br></div><div>Greetings,<br></div><div>Franek<br></div></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic