Hi all,
2013/9/11 Franciszek Boehlke :
> Hi,
> Janek has just pushed newer (still development, though) version of my patch
> to dev/frax/colorful-make branch. It is almost completely rewritten and
> greatly simplified, and fixes several mentioned issues. I'd be happy if you
> give it a try and sha
Hi,
Janek has just pushed newer (still development, though) version of my patch
to dev/frax/colorful-make branch. It is almost completely rewritten and
greatly simplified, and fixes several mentioned issues. I'd be happy if you
give it a try and share with your feedback.
Especially if you've tried
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 (interpre
On 20/08/2013 9:00 AM, Phil Holmes wrote:
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.
I actually don't mind this, provided I can turn it off. I think it's
- Original Message -
From: "Janek Warchol"
To: "David Kastrup"
Cc: "Thomas Morley" ; "LilyPond Developmet Team"
Sent: Monday, August 19, 2013 8:33 PM
Subject: Re: colorful make output! yum!
Hi,
2013/8/15 David Kastrup :
Franciszek Boe
On 2013-08-19, at 15:33 , Janek Warchoł wrote:
> 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.
Pardon me for butting in, but is maintaining this feature better than
Hi,
2013/8/15 David Kastrup :
> Franciszek Boehlke 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 r
>
> If we have a subsystem depend on continued support by a single person,
> it must be easy to remove the subsystem as a whole.
Yes, that's true. However, when I replace @s with some variable (which i'm
going to do), all changes are going to be removable by just a few regex
replacements, I belie
Franciszek Boehlke 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 th
Maybe I just missed some solution (possibly I don't know about some make
capabilities in that area), but I don't think it's possible to be done
without changing current rules. It is because output is in many cases
specific for these rules (e.g. contains name of used program). I mean, now
it print
Franciszek Boehlke writes:
> The result looks nice but if you want any chance of putting this in, it
> should be rewritten as a make post-processor (IMHO of course), think
>
> I like the idea of making is make post-processor, but I don't think it's
> possible to do - and if not, it is much
Hi,
thanks for your replies, and thanks Janek for pushing and advertising my
patch :)
Janek has pushed a bit newer version just a few minutes ago (it doesn't
change anything important, just colorizes 2 more rules, and everything is
squashed into one commit).
We have enough trouble maintaining ou
Janek Warchoł writes:
> my cousin Franek changed the output of make from a heap of unreadable
> gobbledygook to some delicious eye-candy! Checkout branch
> dev/frax/colorful-make and build lilypond. How do you like it?
The result looks nice but if you want any chance of putting this in, it
shou
Janek Warchoł writes:
> Hi,
>
> my cousin Franek changed the output of make from a heap of unreadable
> gobbledygook to some delicious eye-candy! Checkout branch
> dev/frax/colorful-make and build lilypond. How do you like it?
>
> As for me, i can spend whole day just looking at lilypond being
14 matches
Mail list logo