[Top][All Lists]

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

Re: python include path oddity with "make install"

From: David Kastrup
Subject: Re: python include path oddity with "make install"
Date: Fri, 20 Jan 2017 10:34:48 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

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/
> 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
> 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 
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.$(local_lilypond_datadir) $(INSTALL) -d $(DESTDIR)$(local_lilypond_datadir) = @build_package_datadir@ = $(local_package_datadir) = $(local_package_datadir) = $(lilypond_datadir)/vim
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
python/ d in ['@lilypond_datadir@',
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

reply via email to

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