lilypond-devel
[Top][All Lists]
Advanced

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

Re: Relocation


From: Werner LEMBERG
Subject: Re: Relocation
Date: Sat, 09 Feb 2019 22:37:57 +0100 (CET)

>> 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)?

It has been implemented like this by Hanwen and Jan.

> 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.

Good idea, thanks.

> 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?

Yes, this is my plan.

> 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.

Overrides in #6 don't affect lilypond's data directory.

> Maybe I didn't get that you might have designed #6 not for
> relocation of LilyPond itself, but for its dependencies (GS,
> Fontconfig, Guile...).

Exactly.

> 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?

Again, this is code from Hanwen and Jan, but it should be easy to
change that.  However, ...

> Something like $INSTALLER_PREFIX/etc/lilypond-relocate or
> $INSTALLER_PREFIX/etc/lilypond/relocate.

... I think this is not necessary.  I'm not aware of any other program
that uses a similar mechanism with a `relocate' directory to set
environment variables needed internally.

>> 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?

Actually no.  It's rather that the current code doesn't cover all
cases.  For example, if you call lilypond as `./lilypond' (i.e., you
are in the binary's directory), you get a wrong relocation path for
the datadir.  On the other hand, if relocation fails, there is no
compile-time datadir defined at all...


    Werner



reply via email to

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