Re: python include path oddity with "make install"

[David Kastrup]

Graham Percival <address@hidden> 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:

address@hidden:/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