[Top][All Lists]

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

Re: Hardcoded LP version in *2ly scripts?

From: Graham Percival
Subject: Re: Hardcoded LP version in *2ly scripts?
Date: Tue, 28 Dec 2010 00:36:59 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

On Mon, Dec 27, 2010 at 05:26:43PM -0700, Colin Campbell wrote:
> On Mon, 2010-12-27 at 23:14 +0000, Graham Percival wrote:
> > Yes, this is correct and done in the GUB building.
> Just for curiosity, would it be feasible to code them to use the latest
> version of lilypond installed in /usr?

Given that GUB doesn't need to be installed in /usr, that doesn't
make sense.  Also, I can't see any benefit to allowing a mismatch
between data files and program files -- if all goes well, it would
be just the same as having program files of the same version as
the data; if it goes poorly, it'd be a huge jumbled mess.

> IOW, is there enough change between LP versions to create such a
> tight dependence as to require hard-coding?

Perhaps not /require/ -- but given that the installer must have a
copy of the new python scripts anyway (in case it's going to be
used as a new install rather than an upgrade), what's the harm in
doing so?

Technically yes, we could construct an "upgrade only" package,
which might be able to save 500kb of download due to not coupling
the program+data for python scripts.  I'm guessing 50kb at most,
though.  We'd see at least 20 people a year downloading that
instead of the installer and getting into troubles, making it a
support nightmare.

I really don't see this as a fruitful area of speculation.  If we
wanted to go the "upgrade-only" route, then bsdiff is the way to
we could probably get between-2.13 deltas down to 1 meg or so.  Of
course, we'd have to explain to people how to use bsdiff (a simple
command-line utility, but that's not trivial for windows and osx

> > If anybody is seriously interested in the build system details,
> > the source is there; me spending a few hours trying to explain it
> > would be less useful than spending that time towards getting 2.14
> > out.
> Someday, I'd love to find out how the recursive directory links come
> about: I tried to grep -R 2ly over ~/lilypond-git and was taken quite
> aback at how huffy grep gets about recursion loops!

For searching, use:  git grep "foo"

- GRaham

reply via email to

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