lilypond-user
[Top][All Lists]
Advanced

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

Re: Which Linux distro for Lilypond


From: H. S. Teoh
Subject: Re: Which Linux distro for Lilypond
Date: Sat, 7 Jan 2017 10:46:25 -0800
User-agent: NeoMutt/20161126 (1.7.1)

On Sat, Jan 07, 2017 at 09:59:22AM +0100, David Kastrup wrote:
> "H. S. Teoh" <address@hidden> writes:
[...]
> > I've been able to get Lilypond 2.19 to work in Debian/testing by
> > compiling from source (lilypond git HEAD) with `./configure
> > --enable-guile2`.  There are some Scheme-related deprecation warning
> > messages that show up while lilypond is running, but otherwise it
> > seems to be working just fine.
> 
> If you never use a non-ASCII character and are satisfied with the
> speed of LilyPond dropping to less than a third and its memory
> requirements rising.
> 
> This is not a viable option for serious work.
[...]

Unfortunately, I think you're right. :-(  I've noticed that my newly
compiled lilypond now takes a very noticeable long pause just at startup
time, and seems more sluggish to work through complex scores in general.

I didn't realize there was so much going on with the transition (or lack
thereof?) to guile 2.0.  What of the idea of packaging the last
known-to-be-good version of guile 1.8 with the lilypond sources, and
just going with that?

After having witnessed several such problems with large software
projects (namely, depending on an external library that upstream no
longer maintains, and the new version is not backward compatible), and
having experienced the same thing myself in my own projects, I'm
starting more and more to question the wisdom of depending on external
libraries.  The most practical approach that I'm gradually adopting,
especially for open-source libraries, is to just ship the exact version
of the library that I develop on and test with along with my sources,
and not have to worry about dependency hell (including, by extension,
library upgrade hell) on the users' end.


T

-- 
Heuristics are bug-ridden by definition. If they didn't have bugs, they'd be 
algorithms.



reply via email to

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