Re: AU-1.2 Relocation
> I wonder if "bindir/.." shouldn't be "../bindir" (my parents being up > in the genealogy). Nope, as others have already confirmed :-) Werner
Re: AU-1.2 Relocation
Am 25.03.20 um 17:19 schrieb Jean-Charles Malahieude:
Hi Werner,
On my way to updating the French documentation, I read in running.itely
(1st item of Relocation algorithm)
"Compute the directory where the currently executed
@command{lilypond} binary is located. Let's call this
@code{bindir}. Set (internal) environment variable
@code{INSTALLER_PREFIX} to @file{@var{bindir}/..} (i.e., the
parent directory of @code{bindir})."
I wonder if "bindir/.." shouldn't be "../bindir" (my parents being up in
the genealogy).
The parent directory of bindir is bindir/..
../bindir would be a sibling (called bindir) of the working directory.
Re: AU-1.2 Relocation
bindir/.. is the parent directory of bindir
../bindir is the directory bindir that is a child of the parent of the current
directory.
Carl
On 3/25/20, 10:27 AM, "lilypond-devel on behalf of Jean-Charles Malahieude"
wrote:
Hi Werner,
On my way to updating the French documentation, I read in running.itely
(1st item of Relocation algorithm)
"Compute the directory where the currently executed
@command{lilypond} binary is located. Let's call this
@code{bindir}. Set (internal) environment variable
@code{INSTALLER_PREFIX} to @file{@var{bindir}/..} (i.e., the
parent directory of @code{bindir})."
I wonder if "bindir/.." shouldn't be "../bindir" (my parents being up in
the genealogy).
Would you mind confirming my assumption?
If "../bindir" is the right spelling, I'll change it on Translation's
branch and it will be merged into staging afterwards.
Cheers,
--
Jean-Charles
AU-1.2 Relocation
Hi Werner,
On my way to updating the French documentation, I read in running.itely
(1st item of Relocation algorithm)
"Compute the directory where the currently executed
@command{lilypond} binary is located. Let's call this
@code{bindir}. Set (internal) environment variable
@code{INSTALLER_PREFIX} to @file{@var{bindir}/..} (i.e., the
parent directory of @code{bindir})."
I wonder if "bindir/.." shouldn't be "../bindir" (my parents being up in
the genealogy).
Would you mind confirming my assumption?
If "../bindir" is the right spelling, I'll change it on Translation's
branch and it will be merged into staging afterwards.
Cheers,
--
Jean-Charles
Re: Relocation
> > 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. OK, this point is probably obvious in the larger context of the documentation or by looking at the code. With this in mind, the last revised algorithm you sent looks good to me. Best -- John Mandereau ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Relocation
>> 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. Here's an updated version of the algorithm, which is now pretty simple and thus probably better :-) Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 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)? 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Relocation
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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Relocation
Folks, 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.[*] Right now, lilypond's behaviour is quite erratic and has some bugs... Werner [*] Note that the planned environment variable LILYPOND_RELOCDIR doesn't exist yet. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve relocation debug messages. (issue 347070043 by lemzw...@googlemail.com)
On Feb 8, 2019, at 07:05, d...@gnu.org wrote:
>
> string
> _f (char const *format, const string , const string , const string
> )
> {
> return String_convert::form_string (gettext (format), s.c_str (),
> s2.c_str (),
> s3.c_str ());
> }
>
> anyway. Frankly, my approach would be to throw that function out. It
> just obfuscates what will and what will not work and keeps GCC from
> issuing warnings when number and uses of %s don't match.
+1 (but I’m not volunteering)
—
Dan
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve relocation debug messages. (issue 347070043 by lemzw...@googlemail.com)
Frankly, my approach would be to throw that function out. It just obfuscates what will and what will not work and keeps GCC from issuing warnings when number and uses of %s don't match. Hmm. Having a C++ version of `_f' is actually quite nice, since appending `c_str' again and again is a nuisance IMHO. Could you come up with a better replacement? If this is not possible please go ahead and clean up the code. https://codereview.appspot.com/347070043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve relocation debug messages. (issue 347070043 by lemzw...@googlemail.com)
On 2019/02/08 11:41:45, lemzwerg wrote:
> Can you give any reason why it _should_ work rather than "I tried"?
flower/include/international.hh:46
Oh good grief.
string _f (char const *format, ...)
__attribute__ ((format (printf, 1, 2)));
string _f (char const *format, const string , const string = "",
const string = "");
So this is a format-like string unless there follow 1 to 3 C++ strings
(or types convertible to strings) in which case GCC does not get to
check argument consistency. And the code then does
string
_f (char const *format, const string , const string , const string
)
{
return String_convert::form_string (gettext (format), s.c_str (),
s2.c_str (),
s3.c_str ());
}
anyway. Frankly, my approach would be to throw that function out. It
just obfuscates what will and what will not work and keeps GCC from
issuing warnings when number and uses of %s don't match.
https://codereview.appspot.com/347070043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve relocation debug messages. (issue 347070043 by lemzw...@googlemail.com)
Can you give any reason why it _should_ work rather than "I tried"? flower/include/international.hh:46 https://codereview.appspot.com/347070043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve relocation debug messages. (issue 347070043 by lemzw...@googlemail.com)
On 2019/02/08 09:49:58, lemzwerg wrote: On 2019/02/08 09:42:27, dak wrote: > https://codereview.appspot.com/347070043/diff/1/lily/relocate.cc > File lily/relocate.cc (right): > > https://codereview.appspot.com/347070043/diff/1/lily/relocate.cc#newcode128 > lily/relocate.cc:128: TOPLEVEL_VERSION, package_datadir)); > Why no .c_str () here (and lots of other places)? Why should it? It works without `c_str'. Am I missing something? Well, we do prefer code that works by design rather than code that works by mere chance and due to idiosyncrasies of the GNU C++ library. _f needs zero-terminated strings for %s format fields but being a C-style format string, cannot enforce the respective conversions. Can you give any reason why it _should_ work rather than "I tried"? https://codereview.appspot.com/347070043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Improve relocation debug messages. (issue 347070043 by lemzw...@googlemail.com)
Reviewers: dak, Message: On 2019/02/08 09:42:27, dak wrote: https://codereview.appspot.com/347070043/diff/1/lily/relocate.cc File lily/relocate.cc (right): https://codereview.appspot.com/347070043/diff/1/lily/relocate.cc#newcode128 lily/relocate.cc:128: TOPLEVEL_VERSION, package_datadir)); Why no .c_str () here (and lots of other places)? Why should it? It works without `c_str'. Am I missing something? Description: Improve relocation debug messages. This patch contains the following commits. * relocate.cc: Don't use double forward slashes in file names. * main.cc, relocate.cc: Improve relocation debug messages. This commit does the following. * Add `_f ()' where necessary. * Improve readability of code by omitting some `.c_str ()' conversions. * Synchronize formatting of messages. * Improve messages to make the more readable. Also add some new ones. * Indent all messages related to relocation. * relocate.cc: Add `indent' parameter to `sane_putenv'. We are going to use that to provide better formatting of debug messages. Please review this at https://codereview.appspot.com/347070043/ Affected files (+67, -38 lines): M lily/include/relocate.hh M lily/main.cc M lily/relocate.cc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Improve relocation debug messages. (issue 347070043 by lemzw...@googlemail.com)
https://codereview.appspot.com/347070043/diff/1/lily/relocate.cc File lily/relocate.cc (right): https://codereview.appspot.com/347070043/diff/1/lily/relocate.cc#newcode128 lily/relocate.cc:128: TOPLEVEL_VERSION, package_datadir)); Why no .c_str () here (and lots of other places)? https://codereview.appspot.com/347070043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tidies binary relocation (issue 6463066)
- Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: philehol...@googlemail.com; d...@gnu.org; lilypond-devel@gnu.org; re...@codereview-hr.appspotmail.com Sent: Saturday, August 18, 2012 7:29 PM Subject: Re: Tidies binary relocation (issue 6463066) On Sat, Aug 18, 2012 at 03:40:19PM +0100, Phil Holmes wrote: - Original Message - From: gra...@percival-music.ca To: philehol...@googlemail.com; d...@gnu.org Cc: re...@codereview-hr.appspotmail.com; lilypond-devel@gnu.org I haven't looked at the new logic in detail, but exactly what was LILYPOND_RELOCATE_PREFIX doing, and why do we no longer need it? If TBH, I have no idea. It relies on an environment variable that has no mention in our docs anywhere, and the only reference I can find to it at all is an email message from 2006, where using it didn't fix the problem anyway. That doesn't necessarily anything. It could be used in GUB for building, or lilypad-osx or lilypad-windows for compiling. I must admit that I've grepped for it in both git repositories and couldn't find it, though. It might even be involved in the lilypond jail settings (i.e. for LSR). (and note that unless you have personally set up a working LSR, do not assume that the docs on lilypond jail actually work!) I did the same. It's not just that it doean't appear anywhere in our build system - it doesn't appear anywhere on t'internet, either. If anyone can say what it's used for, we could document it. But I don't think we should rely on reading the C++ code to find all the environment variables we could use... OTOH, I don't think that we should delete bits of code unless we know why they were there in the first place. There's just so many dark corners of lilypond that no active developers are familiar with. I think we should do some sweeping up in cobwebby corners, if we can. In particular, when we can't find any reason for the code to be there in the first place. I've not worked out yet how to get git to show which commit put that code in. If someone could either do that, or explain how to, I think it could help. I'm not saying that I'm completely opposed to having this in git master. I'd feel better if you made some binaries and asked users to test them first. But even without that, as long as you'll be around in Sep to revert this patch if necessary, I think it could still go forward. I've made binaries and tested them under Ubuntu. The code is not windows specific, it's OS independent. It relies on someone setting the environment value LILYPOND_RELOCATE_PREFIX which could work on any OS. So I think the only way to get enough people to test would be to put it into a release and see if anyone complains. I would revert in that case. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tidies binary relocation (issue 6463066)
Phil Holmes em...@philholmes.net writes: I think we should do some sweeping up in cobwebby corners, if we can. In particular, when we can't find any reason for the code to be there in the first place. I've not worked out yet how to get git to show which commit put that code in. If someone could either do that, or explain how to, I think it could help. git grep LILYPOND_RELOCATE_PREFIX Documentation/misc/ChangeLog-2.10: * lily/main.cc (setup_paths): fix: LILYPOND_RELOCATE_PREFIX. Documentation/misc/ChangeLog-2.10: * lily/main.cc (setup_paths): read LILYPOND_RELOCATE_PREFIX lily/relocate.cc: if (getenv (LILYPOND_RELOCATE_PREFIX)) lily/relocate.cc: prefix_directory = getenv (LILYPOND_RELOCATE_PREFIX); git gui blame lily/relocate.cc /RELOCATE_PREFIX Click on line. There are some cases: commit 38e0fd809d01de319d40224b5d2279888304b2d3 Author: Jan Nieuwenhuizen jann...@gnu.org Fri Feb 2 13:06:30 2007 Committer: Jan Nieuwenhuizen jann...@gnu.org Fri Feb 2 13:06:30 2007 Finish rename of LILYPONDPREFIX to LILYPOND_DATADIR. Remove confusion between prefix (/usr) and lilypond_datadir (/usr/share/lilypond/x.y.x), fixes running from compile prefix and build tree with `current' link. commit 38e0fd809d01de319d40224b5d2279888304b2d3 Author: Jan Nieuwenhuizen jann...@gnu.org Fri Feb 2 13:06:30 2007 Committer: Jan Nieuwenhuizen jann...@gnu.org Fri Feb 2 13:06:30 2007 Finish rename of LILYPONDPREFIX to LILYPOND_DATADIR. Remove confusion between prefix (/usr) and lilypond_datadir (/usr/share/lilypond/x.y.x), fixes running from compile prefix and build tree with `current' link. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tidies binary relocation (issue 6463066)
On 19 Aug 2012, at 10:27, Phil Holmes em...@philholmes.net wrote: -- -- - Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: philehol...@googlemail.com; d...@gnu.org; lilypond-devel@gnu.org; re...@codereview-hr.appspotmail.com Sent: Saturday, August 18, 2012 7:29 PM Subject: Re: Tidies binary relocation (issue 6463066) On Sat, Aug 18, 2012 at 03:40:19PM +0100, Phil Holmes wrote: - Original Message - From: gra...@percival-music.ca To: philehol...@googlemail.com; d...@gnu.org Cc: re...@codereview-hr.appspotmail.com; lilypond-devel@gnu.org I haven't looked at the new logic in detail, but exactly what was LILYPOND_RELOCATE_PREFIX doing, and why do we no longer need it? If TBH, I have no idea. It relies on an environment variable that has no mention in our docs anywhere, and the only reference I can find to it at all is an email message from 2006, where using it didn't fix the problem anyway. That doesn't necessarily anything. It could be used in GUB for building, or lilypad-osx or lilypad-windows for compiling. I must admit that I've grepped for it in both git repositories and couldn't find it, though. It might even be involved in the lilypond jail settings (i.e. for LSR). (and note that unless you have personally set up a working LSR, do not assume that the docs on lilypond jail actually work!) I did the same. It's not just that it doean't appear anywhere in our build system - it doesn't appear anywhere on t'internet, either. Seriously? Peter Kay memes? It's the future! James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tidies binary relocation (issue 6463066)
On Sun, Aug 19, 2012 at 10:27:37AM +0100, Phil Holmes wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net OTOH, I don't think that we should delete bits of code unless we know why they were there in the first place. There's just so many dark corners of lilypond that no active developers are familiar with. I think we should do some sweeping up in cobwebby corners, if we can. In particular, when we can't find any reason for the code to be there in the first place. I've not worked out yet how to get git to show which commit put that code in. If someone could either do that, or explain how to, I think it could help. gitk lily/relocate.cc lily/include/relocate.hh you can list as many (or as few) files as you want to get only the history specific to those file(s). Adding an entire directory will give you everything for all files in that directory (and subdirectories). I'm not saying that I'm completely opposed to having this in git master. I'd feel better if you made some binaries and asked users to test them first. But even without that, as long as you'll be around in Sep to revert this patch if necessary, I think it could still go forward. I've made binaries and tested them under Ubuntu. The code is not windows specific, it's OS independent. It relies on someone setting the environment value LILYPOND_RELOCATE_PREFIX which could work on any OS. Yes, but that environment variable could be set up by the OSX .app or the windows installer. I agree that in this case it seems unlikely since we haven't found that string in the lilypad or gub repositories, though. But I wanted to note that environment variables don't require the user to set them up specifically. So I think the only way to get enough people to test would be to put it into a release and see if anyone complains. I would revert in that case. There *is* another way: build binaries, upload to your server, email -user asking for volunteers to test them. I used to do this quite a bit when I was working on GUB back in Fall 2009. Yes, it's more work, but OTOH it meant that I wasn't treating git master as an testing ground. The lilypond developer community is getting pickier about only putting patches into master if there's evidence that they do no harm -- that's the whole point of the reviews and Patchy. When it comes to build system stuff, unfortunately there's no way to test it on a single platform. That said, don't take this as a vote against the patch. I'm ok with it going through. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Tidies binary relocation (issue 6463066)
Reviewers: dak, Graham Percival,
Message:
Please review
Description:
I found this code while trying to work out how to get lilypond to run
from the command line with the windows PATH statement. There are
pointless if statements, and the use of a now undocumented environment
variable. This patch tidies that up.
Please review this at http://codereview.appspot.com/6463066/
Affected files:
M lily/relocate.cc
Index: lily/relocate.cc
diff --git a/lily/relocate.cc b/lily/relocate.cc
index
0d600820ae0fa977029b7e439aaae2a4ba86c9e6..3b6a57b715c2e3fbbc06bc3a06676d3c8d581732
100644
--- a/lily/relocate.cc
+++ b/lily/relocate.cc
@@ -165,70 +165,56 @@ setup_paths (char const *argv0_ptr)
if (relocate_binary)
{
string prefix_directory;
- if (getenv (LILYPOND_RELOCATE_PREFIX))
+ string argv0_abs;
+ if (argv0_filename.is_absolute ())
{
- prefix_directory = getenv (LILYPOND_RELOCATE_PREFIX);
-#ifdef __MINGW32__
- /* Normalize file name. */
- prefix_directory = File_name (prefix_directory).to_string ();
-#endif /* __MINGW32__ */
-
- prefix_relocation (prefix_directory);
- string bindir = prefix_directory + /bin;
- framework_relocation (bindir);
+ argv0_abs = argv0_filename.to_string ();
+ debug_output (_f (Relocation: is absolute: argv0=%s\n,
argv0_ptr));
}
- else if (relocate_binary)
+ else if (argv0_filename.dir_.length ())
{
- string argv0_abs;
- if (argv0_filename.is_absolute ())
-{
- argv0_abs = argv0_filename.to_string ();
- debug_output (_f (Relocation: is absolute: argv0=%s\n,
argv0_ptr));
-}
- else if (argv0_filename.dir_.length ())
-{
- argv0_abs = get_working_directory ()
- + / + string (argv0_filename.to_string ());
- debug_output (_f (Relocation: from cwd: argv0=%s\n,
argv0_ptr));
-}
- else
-{
- /* Find absolute ARGV0 name, using PATH. */
- File_path path;
- path.parse_path (getenv (PATH));
+ argv0_abs = get_working_directory ()
+ + / + string (argv0_filename.to_string ());
+ debug_output (_f (Relocation : from cwd: argv0=%s\n,
argv0_ptr));
+}
+ else
+{
+ /* Find absolute ARGV0 name, using PATH. */
+ File_path path;
+ path.parse_path (getenv (PATH));
#ifndef __MINGW32__
- argv0_abs = path.find (argv0_filename.to_string ());
+ argv0_abs = path.find (argv0_filename.to_string ());
#else /* __MINGW32__ */
- path.prepend (get_working_directory ());
- char const *ext[] = {exe, , 0 };
- argv0_abs = path.find (argv0_filename.to_string (), ext);
+ path.prepend (get_working_directory ());
+ char const *ext[] = {exe, , 0 };
+ argv0_abs = path.find (argv0_filename.to_string (), ext);
#endif /* __MINGW32__ */
- debug_output (_f (Relocation: from PATH=%s\nargv0=%s,
-path.to_string ().c_str (), argv0_ptr),
true);
+ debug_output (_f (Relocation: from PATH=%s\nargv0=%s\n,
+path.to_string ().c_str (), argv0_ptr), true);
- if (argv0_abs.empty ())
-programming_error (cannot find absolute argv0);
-}
+ if (argv0_abs.empty ())
+programming_error (cannot find absolute argv0);
+}
- string bindir = dir_name (argv0_abs);
- string argv0_prefix = dir_name (bindir);
- string compile_prefix = dir_name (dir_name (dir_name
(lilypond_datadir)));
- if (argv0_prefix != compile_prefix)
-{
- prefix_relocation (argv0_prefix);
- prefix_directory = argv0_prefix;
-}
- if (argv0_prefix != compile_prefix || string
(FRAMEWORKDIR) != ..)
-{
- framework_relocation (bindir + / + FRAMEWORKDIR);
- prefix_directory = bindir + / + FRAMEWORKDIR;
-}
+ string bindir = dir_name (argv0_abs);
+ string argv0_prefix = dir_name (bindir);
+ string compile_prefix = dir_name (dir_name (dir_name
(lilypond_datadir)));
+ if (argv0_prefix != compile_prefix)
+{
+ prefix_relocation (argv0_prefix);
+ prefix_directory = argv0_prefix;
}
+ if (argv0_prefix != compile_prefix || string (FRAMEWORKDIR) != ..)
+{
+ framework_relocation (bindir + / + FRAMEWORKDIR);
+ prefix_directory = bindir + / + FRAMEWORKDIR;
+}
+
lilypond_datadir = prefix_directory
- + /share/lilypond/ TOPLEVEL_VERSION;
+ + /share/lilypond/ TOPLEVEL_VERSION;
}
if (getenv (LILYPONDPREFIX
Re: Tidies binary relocation (issue 6463066)
I haven't looked at the new logic in detail, but exactly what was LILYPOND_RELOCATE_PREFIX doing, and why do we no longer need it? If that was the environment variable that allowed me to build the documentation on osx without compiling lilypond, then I would be sad to see it go. http://codereview.appspot.com/6463066/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tidies binary relocation (issue 6463066)
- Original Message -
From: gra...@percival-music.ca
To: philehol...@googlemail.com; d...@gnu.org
Cc: re...@codereview-hr.appspotmail.com; lilypond-devel@gnu.org
Sent: Saturday, August 18, 2012 3:19 PM
Subject: Re: Tidies binary relocation (issue 6463066)
I haven't looked at the new logic in detail, but exactly what was
LILYPOND_RELOCATE_PREFIX doing, and why do we no longer need it? If
that was the environment variable that allowed me to build the
documentation on osx without compiling lilypond, then I would be sad to
see it go.
http://codereview.appspot.com/6463066/
TBH, I have no idea. It relies on an environment variable that has no
mention in our docs anywhere, and the only reference I can find to it at all
is an email message from 2006, where using it didn't fix the problem anyway.
If anyone can say what it's used for, we could document it. But I don't
think we should rely on reading the C++ code to find all the environment
variables we could use...
The main reason I started to edit this is because it had the construct:
if (x)
{
if (x)
{
}
}
which doesn't seem too good. Whilst trying to work out what that was doing,
I concluded the relocate bit couldn't do anything either, since no-one would
know about it.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tidies binary relocation (issue 6463066)
On Sat, Aug 18, 2012 at 03:40:19PM +0100, Phil Holmes wrote: - Original Message - From: gra...@percival-music.ca To: philehol...@googlemail.com; d...@gnu.org Cc: re...@codereview-hr.appspotmail.com; lilypond-devel@gnu.org I haven't looked at the new logic in detail, but exactly what was LILYPOND_RELOCATE_PREFIX doing, and why do we no longer need it? If TBH, I have no idea. It relies on an environment variable that has no mention in our docs anywhere, and the only reference I can find to it at all is an email message from 2006, where using it didn't fix the problem anyway. That doesn't necessarily anything. It could be used in GUB for building, or lilypad-osx or lilypad-windows for compiling. I must admit that I've grepped for it in both git repositories and couldn't find it, though. It might even be involved in the lilypond jail settings (i.e. for LSR). (and note that unless you have personally set up a working LSR, do not assume that the docs on lilypond jail actually work!) If anyone can say what it's used for, we could document it. But I don't think we should rely on reading the C++ code to find all the environment variables we could use... OTOH, I don't think that we should delete bits of code unless we know why they were there in the first place. There's just so many dark corners of lilypond that no active developers are familiar with. I'm not saying that I'm completely opposed to having this in git master. I'd feel better if you made some binaries and asked users to test them first. But even without that, as long as you'll be around in Sep to revert this patch if necessary, I think it could still go forward. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: relocation problems on linuxppc
Han-Wen Nienhuys wrote: I'm not sure what is the right solution; the utf8 file uses CJK fonts, which is otherwise a pretty much untested area for Linux/PPC. It might very well be that it never worked correctly. If you happen to have the MacOS box lying around, it would be interesting to see whether you can make GS load the same font (TTF, I presume) on Darwin/PPC. Assuming that Darwin/PPC means OSX (instead of that weird osx-without-a-gui darwin project), then yes; lilypond compiled the same file without any problems at all. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
relocation problems on linuxppc
Mats Bengtsson wrote: Graham Percival wrote: Debian etch, linux/PPC, git head. I have no trouble compiling this file on OSX/intel. I had some trouble getting international stuff set up (well, I forgot that I needed to install the packages), but now files such as input/regression/utf-8.ly and input/sakura-sakura.ly are working fine. This _is_ a new system, and the first time I've ever tried out the linux binaries, so I might be missing something obvious. I don't really understand. On the first line you said git head and here you say ppc binary. Did you use the installation package from lilypond.org or did you compile yourself from git head? I'm trying to build the documentation from git head, using the lilypond binary. For the past year and a half, I've been building the docs on OSX using the OSX binaries; now I'm trying to do the same thing on linux. I suppose that I could try to compile lilypond now that I'm on linux, but I'd prefer to use precompiled binaries using the same extra libraries and whatnot. For the rest of this email, I'm not trying to make the entire docs; I'm simply trying to do lilypond input/typography-demo.ly This tells you that Ghostscript failed converting the file. The messages below are probably a consequence of this Ghostscript problem. I don't think it's because of any Guile problems. If you run lilypond --verbose, Mao, I can't believe I forgot that! Sorry! Is it the Ghostscript from the LilyPond installer? Yes, the lilypond version. [EMAIL PROTECTED]:~/usr/src/lilypond/input$ gs --version 8.54 %% in the logs you'll see gs 8.56 There are a few suspicious things. There are some warnings in the relocations, and the LILYPOND_DATADIR seems to be hard-coded -- I installed lilypond (via the shell script installer) into $HOME/usr/lilypond/ , but the LILYPOND_DATADIR is pointing to /usr/share. [EMAIL PROTECTED]:~/usr/src/lilypond/input$ lilypond -V typography-demo.ly GNU LilyPond 2.11.22 warning: Relocation: is absolute: argv0=/home/gperciva/usr//lilypond/usr/bin/lilypond PATH=/home/gperciva/usr/lilypond/usr/bin (prepend) Setting PATH to /home/gperciva/usr/lilypond/usr/bin:/home/gperciva/aaa/bin:/home/gperciva/usr/bin/:/home/gperciva/aaa/bin:/home/gperciva/usr/bin/:/usr/local/bin:/usr/bin:/bin:/usr/games warning: Relocation: compile datadir=, new datadir=/home/gperciva/usr/lilypond/usr/share/lilypond//current warning: Relocation: framework_prefix=/home/gperciva/usr/lilypond/usr/bin/.. Setting INSTALLER_PREFIX to /home/gperciva/usr/lilypond/usr/bin/.. ... Setting PANGO_PREFIX to /home/gperciva/usr/lilypond/usr/bin/../ Relocation file: /home/gperciva/usr/lilypond/usr/bin/../etc/relocate//gs.reloc warning: no such directory: /home/gperciva/usr/lilypond/usr/bin/../share/ghostscript/8.56/fonts for GS_FONTPATH warning: no such directory: /home/gperciva/usr/lilypond/usr/bin/../share/gs/fonts for GS_FONTPATH warning: no such directory: /home/gperciva/usr/lilypond/usr/bin/../share/ghostscript/8.56/Resource for GS_LIB GS_LIB=/home/gperciva/usr/lilypond/usr/bin/../share/ghostscript/8.56/lib (prepend) Setting GS_LIB to /home/gperciva/usr/lilypond/usr/bin/../share/ghostscript/8.56/lib ... LILYPOND_DATADIR=/usr/share/lilypond/2.11.22 LOCALEDIR=/usr/share/locale ... Invoking `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=typography-demo.pdf -c .setpdfwrite -f typography-demo.ps'...GPL Ghostscript SVN PRE-RELEASE 8.56 (2006-05-20) Copyright (C) 2006 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. WARNING: /Unicode /Decoding resource is not accessible but it is useful for generating ToUnicode CMap. Error: /invalidfont in --glyphshow-- Operand stack: 1.1056 0.0 afii57675 0.5203 0.0 afii57673 1.2357 0.0 89.0399 -27.1347 Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1765 1 3 %oparray_pop 1764 1 3 %oparray_pop 1760 1 3 %oparray_pop 1643 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 2 --nostringval-- %repeat_continue --nostringval-- Dictionary stack: --dict:1083/1123(ro)(G)-- --dict:0/20(G)-- --dict:110/200(L)-- Current allocation mode is local Last OS error: 2 Current file position is 18052864 GPL Ghostscript SVN PRE-RELEASE 8.56: Unrecoverable error, exit code 1 `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -sOutputFile=typography-demo.pdf -c .setpdfwrite -f typography-demo.ps' failed (256
Re: relocation problems on linuxppc
2007/4/24, Graham Percival [EMAIL PROTECTED]: [EMAIL PROTECTED]:~/usr/src/lilypond/input$ gs --version 8.54 this is red herring. Lily doesn't run this GS version. %% in the logs you'll see gs 8.56 Copyright (C) 2006 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. WARNING: /Unicode /Decoding resource is not accessible but it is useful for generating ToUnicode CMap. Error: /invalidfont in --glyphshow-- I recently added a patch to Ghostscript to the GUB distribution. Can you check whether this might have been the culprit? (just check a few earlier releases). -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: relocation problems on linuxppc
Han-Wen Nienhuys wrote: Copyright (C) 2006 artofcode LLC, Benicia, CA. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. WARNING: /Unicode /Decoding resource is not accessible but it is useful for generating ToUnicode CMap. Error: /invalidfont in --glyphshow-- I recently added a patch to Ghostscript to the GUB distribution. Can you check whether this might have been the culprit? (just check a few earlier releases). How much earlier ? 2.11.17 and 2.10.9 both had the same problem; 2.10.0-2 had some libc / GLIBC_PRIVATE problem. Should I try 2.8? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: relocation problems on linuxppc
Han-Wen Nienhuys wrote: 2007/4/24, Graham Percival [EMAIL PROTECTED]: I recently added a patch to Ghostscript to the GUB distribution. Can you check whether this might have been the culprit? (just check a few earlier releases). How much earlier ? 2.11.17 and 2.10.9 both had the same problem; 2.10.0-2 had some libc / GLIBC_PRIVATE problem. Should I try 2.8? I'm not sure what is the right solution; the utf8 file uses CJK fonts, which is otherwise a pretty much untested area for Linux/PPC. It might very well be that it never worked correctly. Ok. Let's drop this, then. I was just trying to set up my old powerbook so that I'd have a working system in case I screwed up my macbook OSX - linux shift. If worst comes to worst, I might not be able to update the docs safely for two or three weeks, but that wouldn't be the end of the world. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: relocation problems on linuxppc
2007/4/24, Graham Percival [EMAIL PROTECTED]: Ok. Let's drop this, then. I was just trying to set up my old powerbook so that I'd have a working system in case I screwed up my macbook OSX - linux shift. If worst comes to worst, I might not be able to update the docs safely for two or three weeks, but that wouldn't be the end of the world. the easiest solution would be to disable delete CJK sections locally, and being careful not to push those changes upstream. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: relocation problems on linuxppc
2007/4/24, Graham Percival [EMAIL PROTECTED]: I recently added a patch to Ghostscript to the GUB distribution. Can you check whether this might have been the culprit? (just check a few earlier releases). How much earlier ? 2.11.17 and 2.10.9 both had the same problem; 2.10.0-2 had some libc / GLIBC_PRIVATE problem. Should I try 2.8? I'm not sure what is the right solution; the utf8 file uses CJK fonts, which is otherwise a pretty much untested area for Linux/PPC. It might very well be that it never worked correctly. If you happen to have the MacOS box lying around, it would be interesting to see whether you can make GS load the same font (TTF, I presume) on Darwin/PPC. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
