bug-lilypond
[Top][All Lists]
Advanced

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

Re: Good and bad news about Lilypond 2.9.20 on Windows


From: Mats Bengtsson
Subject: Re: Good and bad news about Lilypond 2.9.20 on Windows
Date: Wed, 04 Oct 2006 13:31:29 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060911 Red Hat/1.0.5-0.1.el4 SeaMonkey/1.0.5




The second problem is new for this release. When I call the program using the native Python package, it doesn't find the lilypond executable, for some strange reason:

I've verified that the lilypond bin directory is at the top of the path and it works to call lilypond from the command line, so the PATH must get lost somewhere along
the way.
Looking again, I realized that the problem was the line
os.environ['PATH'] = bindir + ':' + os.environ['PATH']
since ':' doesn't work as a path separator in Windows. I have no idea why
it has worked earlier, though. Maybe I used to have an extra copy of
C:\Program Files\LilyPond\usr\bin\ in my PATH (but I cannot recall having
changed it recently). Anyway, I'll submit a patch that instead does
os.environ['PATH'] = os.path.join(bindir,os.environ['PATH'])
which should be safe on all platforms.


One additional problem remains, namely the classical CR/LF problem when LilyPond tries
to parse the file snippet-names generated by lilypond-book. It's the line
(string-split (ly:gulp-file f) #\nl)
in scm/lily.scm that cannot handle the Windows line endings.
I'm not sure how to best solve the problem. One possibility would be to
modify gulp_file() in lily/source-file.c, but the comments there explicitly
talks about opening in binary mode to "avoid CR/LF conversions" (which is
what we actually want here). Another would be to replace the current string-split
in lily.scm by something more clever.

  /Mats





reply via email to

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