Am Donnerstag, 26. August 2010, um 11:04:15 schrieb Trevor Daniels: > "Phil Holmes" <m...@philholmes.net> wrote in message > news:i53pqa$tp...@dough.gmane.org... > > Line 4 in the snippet map is > > #(ly:add-file-name-alist '(("3e/lily-0cba8859.ly" . > > "C:\Users\Trevor\LilyPond-git\Documentation\music-glossary.tely") [...] > Your explanation is pretty close. The snippet map in > Windows should contain forward slashes rather than > escaped ones.
Thanks, Trevor, for you bisecting... The culprit is actually not the refactoring, but a bug fix I did before the refactoring (commit 4da9fc65cbf74f4cbbdb01add4d5f341a16f5065 at 10.06.10 13:01). The problem I fixed with it was quite ugly (and I wonder why noone ever ran into it and complained): If your want to run lilypond-book on a file with *.tex, *.html or *.texi extension, you need to use the --output option, because otherwise the input file would be named the same and the input file would be overwritten. Unfortunately, in this particular case (where the file name of the input and the output file was the same), the check for input==output file was terribly broken. Try it out by creating a file test.tex and run lilypond-book --output=out test.tex on it. The first time, it will work and create out/test.tex, but the second time it will complain that the output file is the same as the input file (which it is not!) and refuse to work on the file. In that case, the input filename is simply test.tex, and the output filename is C:/path/to/out/test.tex. The problem was that sooner or later the lilypond- book script changed the current directory to the output directory (after reading in the input file's contents). As a consequence the input filename "test.tex" was now taken relative to the output filename, and then the input and output filenames were really identical. As a solution, I changed the input filename from a relative path (which causes problems as soon as the current working dir is changed in a script) to an absolute path by calling os.path.abspath (...). Unfortunately, os.path.abspath (...) on Windows has the side-effect of changing all / to \. See http://docs.python.org/library/os.path.html I don't really see any other way to turn the input path to an absolute path than calling os.path.abspath, in particular, since the input path can already be an absolute path... Cheers, Reinhold I don't remember how to reproduce the problem, but the issue was that with some files containing include files (involving subdirectories somehow), some output pathes were taken relative to the current working directory. Now, the lilypond-book at some point changed the working directory to the output directory, so those paths were suddenly taken relative to the output directory rather than the input directory. As a solution, I > > Here's what happens now with various releases. > > 2.13.23 and earlier > > Snippet map contains forward slashes, so no problem > > 2.13.24 - 2.13.29 > > lilypondbook fails with pipe problem now, see > http://lists.gnu.org/archive/html/bug-lilypond/2010-07/msg00060.html > so no snippet map is produced. (This seems to depend > on past history or my system as 2.13.26 on one occasion > got further and failed with the snippet map containing > backslashes, and IIRC Eluze reported the msvcrt problem > in this release.) > > 2.13.30 > > lilypondbook fails with msvcrt problem, fixed in 2.13.31 > > 2.13.31 > > Snippet map contains backward slashes, so fails > > Trevor > > > > _______________________________________________ > lilypond-devel mailing list > lilypond-de...@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel -- ------------------------------------------------------------------ Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
