Hardcoded LP version in *2ly scripts?

[Colin Campbell]

Over the course of time, I've kept myself amused with building lilypond
from git by doing the usual make and sudo make install stuff.
Apparently, each successive install created a new folder
in /usr/local/share for each new version installed.  The import scripts
(midi2ly and friends) were left in /usr/local/bin and apparently
untouched by newer installs.

I had occasion to try and run convert-ly (from Frescobaldi, but
LIlyPondTool was the same) over a piece I'd opened in Denemo then saved
as a .ly file. Convert-ly promptly threw an error about not finding
lilylib.  After a bit of a look around, I found that convert-ly had
version 2.13.30 hardwired into a piece of code which looks as though it
is appending to a PATH.  Changing the version by hand ( to 2.13.44)
allowed convert-ly to run.  I also manually deleted all trace of
lilypond, did a fresh git clone and rebuilt; the python scripts now have
the current version. I haven't tested the case of uninstalling the
outdated version, then installing the new build.

It seems reasonable that these routines should be aware of the latest
version of lilypond available, either by being updated during an
install, or by having the path-appending code fetch the version at
runtime.  I've read through the CG and can't find anything which tells
me how the version info gets changed.

If the stuff I'm missing is in the manuals, pointers are gratefully
appreciated. If the CG on building needs a few words, or if the code
needs a low-priority frog-level sort of change, I could see what I can
do.

Colin
-- 
What information consumes is rather obvious: it consumes the attention
of its recipients. Hence a wealth of information creates a poverty of
attention, and a need to allocate that attention efficiently among the
overabundance of information sources that might consume it. - Herbert
Alexander Simon, economist, Nobel laureate (1916-2001)