[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Relocation
From: |
John Mandereau |
Subject: |
Re: Relocation |
Date: |
Sat, 09 Feb 2019 22:08:05 +0100 |
User-agent: |
Evolution 3.30.5 (3.30.5-1.fc29) |
Le samedi 09 février 2019 à 20:56 +0100, Werner LEMBERG a écrit :
> attached are two images that show my planned documentation of
> lilypond's binary relocation. What I'm interested in are comments to
> the relocation algorithm. If we can find an agreement, I'm going to
> fix lilypond to follow it.[*]
Is there a good reason for looking for $INSTALLER_PREFIX subdirectories
(#2) before examining whether LILYPOND_DATADIR and LILYPOND_LOCALEDIR
are already set in the environment (#4 and #5)? I'd rather do this in
the opposite order and put #4 and #5 (as "Use VAR_FOODIR as LilyPond
FOO directory) just after #1, and execute #2 only if LILYPOND_DATADIR
environment variable is unset.
I'm not sure of the semantics of #3: does "relocation is disabled, and
a compile-time value for data directory is used" imply exiting after
this, skipping all the other items? I'd rather put #3 after #6, with
condition "if LilyPond's data directory is still not set", so that
possible overrides defined in #6 can be applied.
Maybe I didn't get that you might have designed #6 not for relocation
of LilyPond itself, but for its dependencies (GS, Fontconfig,
Guile...).
I also have a minor concern with $INSTALLER_PREFIX/etc/relocate: could
we use a less generic path to avoid any clash with other packages in
$INSTALLER_PREFIX? Something like $INSTALLER_PREFIX/etc/lilypond-
relocate or $INSTALLER_PREFIX/etc/lilypond/relocate.
> Right now, lilypond's behaviour is quite
> erratic and has some bugs...
You allude to many issues we had with GUB builds, don't you?
Best
--
John Mandereau
- Relocation, Werner LEMBERG, 2019/02/09
- Re: Relocation,
John Mandereau <=