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
_______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
