Graham Percival writes:
> At the moment, doing:
> mkdir build
> cd build
> ../configure --prefix=$HOME/.local/
> make
> make install
>
> results in python files which can't find lilylib. This is
> installed to:
> $(PREFIX)/share/lilypond/$(VERSION)/python/
>
> The relocation is supposed to be handled by:
> python/relocate-preamble.py.in
> but it seems to assume that "current" is a valid $(VERSION).
> I know that GUB does add a symlink for "current", but that doesn't
> appear to happen for "make install".
>
>
> I can see a few different ways forward:
> - figure out why the @lilypond_datadir@ replacement is going to
> /usr/... instead of $(PREFIX)
> - add a "current" symlink
> - add some more directories to the system path in
> relocate-preamble.py.in
>
> Unfortunately, I've lost a lot of steam on this and am not likely
> to return to it until Feb. I'd rather not hold back the
> pure-python midi2ly change, so it would be awesome if somebody
> else could clarify matters and/or fix it.
Assuming C does not play into it (its own use of lilypond_datadir does
not appear to have any connection to the basic configure/install
process' variants of it: it merely references TOPLEVEL_VERSION as far as
I can see at a glance), I see the following data points here:
dak@lola:/usr/local/tmp/lilypond$ git grep 'lilypond_datadir'|grep -v '^lily/'
Documentation/misc/ChangeLog-1.5: * make/substitute.make (ATVARIABLES):
Add local_lilypond_datadir.
Documentation/misc/ChangeLog-2.1: * make/substitute.make (ATVARIABLES):
Add lilypond_datadir.
GNUmakefile.in:INSTALLATION_DIR=$(local_lilypond_datadir)
GNUmakefile.in: $(INSTALL) -d $(DESTDIR)$(local_lilypond_datadir)
config.make.in:build_lilypond_datadir = @build_package_datadir@
config.make.in:local_lilypond_datadir = $(local_package_datadir)
config.make.in:lilypond_datadir = $(local_package_datadir)
config.make.in:vimdir = $(lilypond_datadir)/vim
ly/GNUmakefile:INSTALLATION_DIR=$(local_lilypond_datadir)/ly
make/substitute.make: lilypond_datadir\
make/substitute.make: local_lilypond_datadir\
mf/GNUmakefile:INSTALLATION_DIR = $(local_lilypond_datadir)/fonts/source
mf/GNUmakefile:INSTALLATION_OUT_DIR1 = $(local_lilypond_datadir)/fonts/otf
mf/GNUmakefile:INSTALLATION_OUT_DIR2 = $(local_lilypond_datadir)/fonts/svg
mf/GNUmakefile:INSTALLATION_OUT_DIR3 = $(local_lilypond_datadir)/fonts
ps/GNUmakefile:INSTALLATION_DIR=$(local_lilypond_datadir)/ps
python/GNUmakefile:INSTALLATION_OUT_DIR1=$(local_lilypond_datadir)/python
python/relocate-preamble.py.in:for d in ['@lilypond_datadir@',
scm/GNUmakefile:INSTALLATION_DIR=$(local_lilypond_datadir)/scm
scripts/build/GNUmakefile:#INSTALLATION_OUT_DIR1=$(local_lilypond_datadir)/scripts
tex/GNUmakefile:INSTALLATION_DIR = $(local_lilypond_datadir)/tex
tex/GNUmakefile:-rmdir $(DESTDIR)$(local_lilypond_datadir)/tex
so we have sort of a parallel diversion of both local_lilypond_datadir
and lilypond_datadir to local_package_datadir .
Judging from the use of $(DESTDIR)$(local_lilypond_datadir), this may be
a relative path. Could that be part of the problem?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel