Graham Percival <gra...@percival-music.ca> 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
