Re: Lilypond build dependency tlasm
Immanuel Litzroth writes: >> On Wed, Sep 7, 2022 at 12:02 PM David Kastrup wrote: >>> >>> But "is this a good idea?" is something people should really consider >>> when coining terms that other people will have to use as a reference. > > In this case the problem seems the font used rather than in the naming. > Immanuel 1 and l are quite similar in a whole lot of fonts, so interspersing letters and digits in this particular manner is asking for trouble. I get a lot of spam that manages to bypass spam filters by relying on graphical similarities of letter glyphs and using different code points. If your target audience are humans instead of spam filters, it makes sense paying attention to such details. -- David Kastrup
Re: Lilypond build dependency tlasm
In this case the problem seems the font used rather than in the naming. Immanuel On Wed, Sep 7, 2022 at 12:02 PM David Kastrup wrote: > > Lukas-Fabian Moser writes: > > > Hi Andrew, > > > > Am 07.09.22 um 10:19 schrieb Andrew Bernard: > >> I cant find out what tlasm is. It's a missing dependency for the > >> build. Google's indexing of billions of pages produces nothing, > >> unless I am dreaming. Could somebody help me understand what this > >> program is and where to find it? > >> > >> ../configure outputs: > >> > >> ERROR: Please install required programs: t1asm > > > > t1asm != tlasm (in uppercase: T1ASM != TLASM) > > There are things like imprudent naming choices that are mistakes waiting > to happen. > > I called an early utility of mine "Preview-LaTeX" and realized with the > first vanity searches that web search engines generally ignore case. > And that I was not exactly entering an empty search space. > > Well, I've dropped the capitalization since then, and clearly by now > that tool (that ended up quite elaborate partly due to a host of > contributors) dominates the search space. > > But "is this a good idea?" is something people should really consider > when coining terms that other people will have to use as a reference. > > -- > David Kastrup > -- -- A man must either resolve to point out nothing new or to become a slave to defend it. -- Sir Isaac Newton
Re: Lilypond build dependency tlasm
Lukas-Fabian Moser writes: > Hi Andrew, > > Am 07.09.22 um 10:19 schrieb Andrew Bernard: >> I cant find out what tlasm is. It's a missing dependency for the >> build. Google's indexing of billions of pages produces nothing, >> unless I am dreaming. Could somebody help me understand what this >> program is and where to find it? >> >> ../configure outputs: >> >> ERROR: Please install required programs: t1asm > > t1asm != tlasm (in uppercase: T1ASM != TLASM) There are things like imprudent naming choices that are mistakes waiting to happen. I called an early utility of mine "Preview-LaTeX" and realized with the first vanity searches that web search engines generally ignore case. And that I was not exactly entering an empty search space. Well, I've dropped the capitalization since then, and clearly by now that tool (that ended up quite elaborate partly due to a host of contributors) dominates the search space. But "is this a good idea?" is something people should really consider when coining terms that other people will have to use as a reference. -- David Kastrup
Re: Lilypond build dependency tlasm
Hi Andrew, Am 07.09.22 um 10:19 schrieb Andrew Bernard: I cant find out what tlasm is. It's a missing dependency for the build. Google's indexing of billions of pages produces nothing, unless I am dreaming. Could somebody help me understand what this program is and where to find it? ../configure outputs: ERROR: Please install required programs: t1asm t1asm != tlasm (in uppercase: T1ASM != TLASM) Lukas
Re: Lilypond build dependency tlasm
> Le 07/09/2022 10:19 CEST, Andrew Bernard a écrit > : > > > I cant find out what tlasm is. It's a missing dependency for the build. > Google's indexing of billions of pages produces nothing, unless I am > dreaming. Could somebody help me understand what this program is and > where to find it? > > ../configure outputs: > > ERROR: Please install required programs: t1asm It's not "tlasm" but "t1asm", the second character is the digit "one" (depending on the font you use, it can be barely noticeable ...). As mentioned on https://lilypond.org/doc/v2.23/Documentation/contributor/requirements-for-compiling-lilypond#other this program is part of the "Type 1 Utilities" suite, e.g. https://packages.ubuntu.com/jammy/t1utils
Re: Lilypond build dependency tlasm
I have no issues when I Google it. Did you search for tlasm or t1asm? Kevin On Wed 7 Sept 2022, 09:51 Andrew Bernard, wrote: > I cant find out what tlasm is. It's a missing dependency for the build. > Google's indexing of billions of pages produces nothing, unless I am > dreaming. Could somebody help me understand what this program is and > where to find it? > > ../configure outputs: > > ERROR: Please install required programs: t1asm > > > Andrew > > > >
Re: Lilypond build dependency tlasm
Oh dear. It's t-one-asm, not t-ell-asm. Sorry for the noise. On 7/09/2022 6:19 pm, Andrew Bernard wrote: I cant find out what tlasm is. It's a missing dependency for the build. Google's indexing of billions of pages produces nothing, unless I am dreaming. Could somebody help me understand what this program is and where to find it? ../configure outputs: ERROR: Please install required programs: t1asm Andrew
Re: Lilypond build dependency tlasm
On 2022-09-07 1:19 am, Andrew Bernard wrote: I cant find out what tlasm is. It's a missing dependency for the build. Google's indexing of billions of pages produces nothing, unless I am dreaming. Could somebody help me understand what this program is and where to find it? ../configure outputs: ERROR: Please install required programs: t1asm That's a numeral one, not a lowercase ell. t1asm [1] is for Type 1 fonts. [1]: https://linux.die.net/man/1/t1asm -- Aaron Hill
Lilypond build dependency tlasm
I cant find out what tlasm is. It's a missing dependency for the build. Google's indexing of billions of pages produces nothing, unless I am dreaming. Could somebody help me understand what this program is and where to find it? ../configure outputs: ERROR: Please install required programs: t1asm Andrew
Re: Lilypond build
Am 18.09.2020 um 16:05 schrieb Federico Bruni: [snip] (./Documentation/out-www/it/web.texi (/usr/share/texlive/texmf-dist/tex/texinfo/texinfo.tex Loading texinfo [version 2019-09-20.22]: pdf, fonts, markup, glyphs, page headings, tables, conditionals, indexing, sectioning, toc, environments, defuns, macros, cross references, insertions, (/usr/share/texlive/texmf-dist/tex/generic/epsf/epsf.tex This is `epsf.tex' v2.7.4 <14 February 2011> ) localization, formatting, and turning on texinfo input format.) (/usr/share/texlive/texmf-dist/tex/texinfo/txi-it.tex no patterns for italian) /Documentation/out-www/it/web.texi:18: I can't find file `macros.itexi'. @temp ->@input macros.itexi Sorry, that was not thought through well enough. Please try the following on top of an already completed doc build. (Start a new shell first, so that changes in the environment do not leak through) I assumed that you did not compile in a separate build directory, but directly in the source directory. bash SRCDIR=~/src/lilypond-git BUILDDIR=$SRCDIR export TEXINPUTS=$SRCDIR/tex:: export TEX=$SRCDIR/scripts/build/xetex-with-options.sh export PDFTEX=$TEX export PDFLATEX=$SRCDIR/scripts/build/xelatex-with-options.sh texi2pdf -I $SRCDIR/Documentation/it -I $BUILDDIR/Documentation/out-www $BUILDDIR/Documentation/out-www/it/web.texi exit Cheers, Michael
Re: Lilypond build
Il giorno ven 18 set 2020 alle 10:18, Michael Käppler ha scritto: Am 18.09.2020 um 00:49 schrieb Federico Bruni: Il giorno mer 16 set 2020 alle 15:39, Michael Käppler ha scritto: Am 16.09.2020 um 13:45 schrieb Michael Käppler: Am 16.09.2020 um 12:18 schrieb Federico Bruni: Il giorno sab 12 set 2020 alle 15:13, Jonas Hahnfeld ha scritto: I think right now it makes most sense to just release 2.21.6 as a "normal" unstable release, without any extra wording. The issue with the Documentation build should again be fixed, so from my perspective you should be good to go (if you have time). I was working on updating the italian website last night (on the translation branch) and I saw a strange error related to texidoc snippets when running 'make doc'. I don't have time to investigate.. perhaps updating the italian texidoc would solve the issue? Trying to reproduce this here, build is running... Completed without errors for me. My steps: git checkout translation ./autogen.sh --noconfigure mkdir build cd build ../configure --enable-gs-api make && make doc I've just run make& doc again. I don't get my previous error anymore. For the records, it was this one: Making Documentation/out-www/it/snippets.texi < tely Command '/home/fede/src/lilypond-git/out/bin/lilypond -dbackend=eps --formats=ps,png,pdf -dinclude-eps-fonts -dgs-load-fonts --header=doctitle --header=doctitleen --header=doctitleca --header=doctitlecs --header=doctitlede --header=doctitlees --header=doctitlefr --header=doctitlehu --header=doctitleit --header=doctitleja --header=doctitlenl --header=doctitlept --header=doctitlezh --header=texidoc --header=texidocen --header=texidocca --header=texidoccs --header=texidocde --header=texidoces --header=texidocfr --header=texidochu --header=texidocit --header=texidocja --header=texidocnl --header=texidocpt --header=texidoczh -dcheck-internal-types -ddump-signatures -danti-alias-factor=2 -I "./" -I "/home/fede/src/lilypond-git/Documentation" -I "/home/fede/src/lilypond-git/Documentation/it" -I "/home/fede/src/lilypond-git/Documentation/it/included" -I "/home/fede/src/lilypond-git/Documentation/it" -I "/home/fede/src/lilypond-git/Documentation/pictures" -I "/home/fede/src/lilypond-git/Documentation/out-www/it" -I "/home/fede/src/lilypond-git/Documentation/out-www/en" -I "/home/fede/src/lilypond-git/Documentation/en" -I "/home/fede/src/lilypond-git/Documentation/en/included" -I "/home/fede/src/lilypond-git/input/regression" -I "/home/fede/src/lilypond-git/Documentation/out-www" -I "/home/fede/src/lilypond-git/Documentation" --formats=eps -deps-box-padding=3.00 -dread-file-list -dno-strip-output-dir "/home/fede/src/lilypond-git/out/lybook-db/snippet-names-0924ca039783b7203dbd935e9c6796d7.ly"' died with . make[2]: *** [../make/lilypond-book-rules.make:6: out-www/it/learning.texi] Error 1 make[2]: *** Deleting file 'out-www/it/learning.texi' make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory '/home/fede/src/lilypond-git/Documentation' make[1]: *** [/home/fede/src/lilypond-git/stepmake/stepmake/generic-targets.make:150: WWW] Error 2 make[1]: Leaving directory '/home/fede/src/lilypond-git' make: *** [/home/fede/src/lilypond-git/stepmake/stepmake/generic-targets.make:155: doc] Errore 2 Hmm... seems to be a segfault. Can you tell what you changed that it works now? Nothing changed in the source... I just ran again `make`, that's the only difference. I'm now getting another error, even though the built docs seem complete. I wonder if it's related to the fact I'm using Texlive 2020. $ tail /home/fede/src/lilypond-git/Documentation/./out-www/it/web.texi2pdf.logl6699: Undefined cross reference `Changes-pg'.)) [172]][172][173][174] xdvipdfmx:warning: Glyph width mismatch for TFM and font (feymr10) xdvipdfmx:warning: TFM: 727.092 vs. Type1 font: 705 2513452 bytes written ) (see the transcript file for additional information) Output written on web.pdf (174 pages). Transcript written on web.log. /usr/bin/texi2dvi: /home/fede/src/lilypond-git/scripts/build/xetex-with-options.sh exited with bad status, quitting. What happens if you run your systems texi2pdf (aka texi2dvi --pdf) directly on Documentation/out-www/it/web.texi ? [fede@localhost lilypond-git (translation)]$ texi2pdf Documentation/out-www/it/web.texi This is pdfTeX, Version 3.14159265-2.6-1.40.21 (TeX Live 2020) (preloaded format=pdfetex) restricted \write18 enabled. entering extended mode (./Documentation/out-www/it/web.texi (/usr/share/texlive/texmf-dist/tex/texinfo/texinfo.tex Loading texinfo [version 2019-09-20.22]: pdf, fonts, markup, glyphs, page headings, tables, conditionals, indexing, sectioning, toc, environments, defuns, macros, cross references, insertions, (/usr/share/texlive/texmf-dist/tex/generic/epsf/epsf.tex This is `epsf.tex' v2.7.4 <14 February 2011> ) localization, formatting, and turning on texinfo input format.)
Re: Lilypond build
Am 18.09.2020 um 00:49 schrieb Federico Bruni: Il giorno mer 16 set 2020 alle 15:39, Michael Käppler ha scritto: Am 16.09.2020 um 13:45 schrieb Michael Käppler: Am 16.09.2020 um 12:18 schrieb Federico Bruni: Il giorno sab 12 set 2020 alle 15:13, Jonas Hahnfeld ha scritto: I think right now it makes most sense to just release 2.21.6 as a "normal" unstable release, without any extra wording. The issue with the Documentation build should again be fixed, so from my perspective you should be good to go (if you have time). I was working on updating the italian website last night (on the translation branch) and I saw a strange error related to texidoc snippets when running 'make doc'. I don't have time to investigate.. perhaps updating the italian texidoc would solve the issue? Trying to reproduce this here, build is running... Completed without errors for me. My steps: git checkout translation ./autogen.sh --noconfigure mkdir build cd build ../configure --enable-gs-api make && make doc I've just run make& doc again. I don't get my previous error anymore. For the records, it was this one: Making Documentation/out-www/it/snippets.texi < tely Command '/home/fede/src/lilypond-git/out/bin/lilypond -dbackend=eps --formats=ps,png,pdf -dinclude-eps-fonts -dgs-load-fonts --header=doctitle --header=doctitleen --header=doctitleca --header=doctitlecs --header=doctitlede --header=doctitlees --header=doctitlefr --header=doctitlehu --header=doctitleit --header=doctitleja --header=doctitlenl --header=doctitlept --header=doctitlezh --header=texidoc --header=texidocen --header=texidocca --header=texidoccs --header=texidocde --header=texidoces --header=texidocfr --header=texidochu --header=texidocit --header=texidocja --header=texidocnl --header=texidocpt --header=texidoczh -dcheck-internal-types -ddump-signatures -danti-alias-factor=2 -I "./" -I "/home/fede/src/lilypond-git/Documentation" -I "/home/fede/src/lilypond-git/Documentation/it" -I "/home/fede/src/lilypond-git/Documentation/it/included" -I "/home/fede/src/lilypond-git/Documentation/it" -I "/home/fede/src/lilypond-git/Documentation/pictures" -I "/home/fede/src/lilypond-git/Documentation/out-www/it" -I "/home/fede/src/lilypond-git/Documentation/out-www/en" -I "/home/fede/src/lilypond-git/Documentation/en" -I "/home/fede/src/lilypond-git/Documentation/en/included" -I "/home/fede/src/lilypond-git/input/regression" -I "/home/fede/src/lilypond-git/Documentation/out-www" -I "/home/fede/src/lilypond-git/Documentation" --formats=eps -deps-box-padding=3.00 -dread-file-list -dno-strip-output-dir "/home/fede/src/lilypond-git/out/lybook-db/snippet-names-0924ca039783b7203dbd935e9c6796d7.ly"' died with . make[2]: *** [../make/lilypond-book-rules.make:6: out-www/it/learning.texi] Error 1 make[2]: *** Deleting file 'out-www/it/learning.texi' make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory '/home/fede/src/lilypond-git/Documentation' make[1]: *** [/home/fede/src/lilypond-git/stepmake/stepmake/generic-targets.make:150: WWW] Error 2 make[1]: Leaving directory '/home/fede/src/lilypond-git' make: *** [/home/fede/src/lilypond-git/stepmake/stepmake/generic-targets.make:155: doc] Errore 2 Hmm... seems to be a segfault. Can you tell what you changed that it works now? I'm now getting another error, even though the built docs seem complete. I wonder if it's related to the fact I'm using Texlive 2020. $ tail /home/fede/src/lilypond-git/Documentation/./out-www/it/web.texi2pdf.logl.6699: Undefined cross reference `Changes-pg'.)) [172]][172][173][174] xdvipdfmx:warning: Glyph width mismatch for TFM and font (feymr10) xdvipdfmx:warning: TFM: 727.092 vs. Type1 font: 705 2513452 bytes written ) (see the transcript file for additional information) Output written on web.pdf (174 pages). Transcript written on web.log. /usr/bin/texi2dvi: /home/fede/src/lilypond-git/scripts/build/xetex-with-options.sh exited with bad status, quitting. What happens if you run your systems texi2pdf (aka texi2dvi --pdf) directly on Documentation/out-www/it/web.texi ? Cheers, Michael
Re: Lilypond build
Il giorno mer 16 set 2020 alle 15:39, Michael Käppler ha scritto: Am 16.09.2020 um 13:45 schrieb Michael Käppler: Am 16.09.2020 um 12:18 schrieb Federico Bruni: Il giorno sab 12 set 2020 alle 15:13, Jonas Hahnfeld ha scritto: I think right now it makes most sense to just release 2.21.6 as a "normal" unstable release, without any extra wording. The issue with the Documentation build should again be fixed, so from my perspective you should be good to go (if you have time). I was working on updating the italian website last night (on the translation branch) and I saw a strange error related to texidoc snippets when running 'make doc'. I don't have time to investigate.. perhaps updating the italian texidoc would solve the issue? Trying to reproduce this here, build is running... Completed without errors for me. My steps: git checkout translation ./autogen.sh --noconfigure mkdir build cd build ../configure --enable-gs-api make && make doc I've just run make& doc again. I don't get my previous error anymore. For the records, it was this one: Making Documentation/out-www/it/snippets.texi < tely Command '/home/fede/src/lilypond-git/out/bin/lilypond -dbackend=eps --formats=ps,png,pdf -dinclude-eps-fonts -dgs-load-fonts --header=doctitle --header=doctitleen --header=doctitleca --header=doctitlecs --header=doctitlede --header=doctitlees --header=doctitlefr --header=doctitlehu --header=doctitleit --header=doctitleja --header=doctitlenl --header=doctitlept --header=doctitlezh --header=texidoc --header=texidocen --header=texidocca --header=texidoccs --header=texidocde --header=texidoces --header=texidocfr --header=texidochu --header=texidocit --header=texidocja --header=texidocnl --header=texidocpt --header=texidoczh -dcheck-internal-types -ddump-signatures -danti-alias-factor=2 -I "./" -I "/home/fede/src/lilypond-git/Documentation" -I "/home/fede/src/lilypond-git/Documentation/it" -I "/home/fede/src/lilypond-git/Documentation/it/included" -I "/home/fede/src/lilypond-git/Documentation/it" -I "/home/fede/src/lilypond-git/Documentation/pictures" -I "/home/fede/src/lilypond-git/Documentation/out-www/it" -I "/home/fede/src/lilypond-git/Documentation/out-www/en" -I "/home/fede/src/lilypond-git/Documentation/en" -I "/home/fede/src/lilypond-git/Documentation/en/included" -I "/home/fede/src/lilypond-git/input/regression" -I "/home/fede/src/lilypond-git/Documentation/out-www" -I "/home/fede/src/lilypond-git/Documentation" --formats=eps -deps-box-padding=3.00 -dread-file-list -dno-strip-output-dir "/home/fede/src/lilypond-git/out/lybook-db/snippet-names-0924ca039783b7203dbd935e9c6796d7.ly"' died with . make[2]: *** [../make/lilypond-book-rules.make:6: out-www/it/learning.texi] Error 1 make[2]: *** Deleting file 'out-www/it/learning.texi' make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory '/home/fede/src/lilypond-git/Documentation' make[1]: *** [/home/fede/src/lilypond-git/stepmake/stepmake/generic-targets.make:150: WWW] Error 2 make[1]: Leaving directory '/home/fede/src/lilypond-git' make: *** [/home/fede/src/lilypond-git/stepmake/stepmake/generic-targets.make:155: doc] Errore 2 I'm now getting another error, even though the built docs seem complete. I wonder if it's related to the fact I'm using Texlive 2020. $ tail /home/fede/src/lilypond-git/Documentation/./out-www/it/web.texi2pdf.logl.6699: Undefined cross reference `Changes-pg'.)) [172]][172][173][174] xdvipdfmx:warning: Glyph width mismatch for TFM and font (feymr10) xdvipdfmx:warning: TFM: 727.092 vs. Type1 font: 705 2513452 bytes written ) (see the transcript file for additional information) Output written on web.pdf (174 pages). Transcript written on web.log. /usr/bin/texi2dvi: /home/fede/src/lilypond-git/scripts/build/xetex-with-options.sh exited with bad status, quitting.
Re: Lilypond build
Am 16.09.2020 um 13:45 schrieb Michael Käppler: Am 16.09.2020 um 12:18 schrieb Federico Bruni: Il giorno sab 12 set 2020 alle 15:13, Jonas Hahnfeld ha scritto: I think right now it makes most sense to just release 2.21.6 as a "normal" unstable release, without any extra wording. The issue with the Documentation build should again be fixed, so from my perspective you should be good to go (if you have time). I was working on updating the italian website last night (on the translation branch) and I saw a strange error related to texidoc snippets when running 'make doc'. I don't have time to investigate.. perhaps updating the italian texidoc would solve the issue? Trying to reproduce this here, build is running... Completed without errors for me. My steps: git checkout translation ./autogen.sh --noconfigure mkdir build cd build ../configure --enable-gs-api make && make doc
Re: Lilypond build
Am 16.09.2020 um 12:18 schrieb Federico Bruni: Il giorno sab 12 set 2020 alle 15:13, Jonas Hahnfeld ha scritto: I think right now it makes most sense to just release 2.21.6 as a "normal" unstable release, without any extra wording. The issue with the Documentation build should again be fixed, so from my perspective you should be good to go (if you have time). I was working on updating the italian website last night (on the translation branch) and I saw a strange error related to texidoc snippets when running 'make doc'. I don't have time to investigate.. perhaps updating the italian texidoc would solve the issue? Trying to reproduce this here, build is running...
Re: Lilypond build
Il giorno sab 12 set 2020 alle 15:13, Jonas Hahnfeld ha scritto: I think right now it makes most sense to just release 2.21.6 as a "normal" unstable release, without any extra wording. The issue with the Documentation build should again be fixed, so from my perspective you should be good to go (if you have time). I was working on updating the italian website last night (on the translation branch) and I saw a strange error related to texidoc snippets when running 'make doc'. I don't have time to investigate.. perhaps updating the italian texidoc would solve the issue?
Re: Lilypond build
Am Freitag, den 11.09.2020, 13:29 +0200 schrieb Jonas Hahnfeld: > Am Freitag, den 11.09.2020, 12:20 +0100 schrieb Phil Holmes: > > I can't work out whether there was consensus on the next released build. > > With nobody else replying, I wouldn't call it consensus. > > > Are we going with 2.21.6 and a release announcement that this is an initial > > pre-release for a new stable 2.22.0? Or perhaps go for 2.21.80 as a > > clearer > > sign that it's a pre-release? > > IMHO the next release from master / unstable should be 2.21.6, with the > bump only happening after branching stable/. > In any case, please do not produce a build right now because > https://gitlab.com/lilypond/lilypond/-/merge_requests/373 > broke the inclusion of snippets into the Documentation build... I think right now it makes most sense to just release 2.21.6 as a "normal" unstable release, without any extra wording. The issue with the Documentation build should again be fixed, so from my perspective you should be good to go (if you have time). Jonas signature.asc Description: This is a digitally signed message part
Re: Lilypond build
Am Freitag, den 11.09.2020, 12:20 +0100 schrieb Phil Holmes: > I can't work out whether there was consensus on the next released build. With nobody else replying, I wouldn't call it consensus. > Are we going with 2.21.6 and a release announcement that this is an initial > pre-release for a new stable 2.22.0? Or perhaps go for 2.21.80 as a clearer > sign that it's a pre-release? IMHO the next release from master / unstable should be 2.21.6, with the bump only happening after branching stable/. In any case, please do not produce a build right now because https://gitlab.com/lilypond/lilypond/-/merge_requests/373 broke the inclusion of snippets into the Documentation build... Jonas signature.asc Description: This is a digitally signed message part
Lilypond build
I can't work out whether there was consensus on the next released build. Are we going with 2.21.6 and a release announcement that this is an initial pre-release for a new stable 2.22.0? Or perhaps go for 2.21.80 as a clearer sign that it's a pre-release? -- Phil Holmes
Re: LilyPond build for windows?
Am Sonntag, den 21.06.2020, 13:35 +0200 schrieb Han-Wen Nienhuys: > On Sun, Jun 21, 2020 at 12:07 PM Jonas Hahnfeld wrote: > > Am Samstag, den 20.06.2020, 20:25 +0200 schrieb Han-Wen Nienhuys: > > > What is the status of our lilypond binary on windows? > > > > > > The GUB based binary used to include a hacked-together Python > > > interpreter, which -due to being cross-compiled- had some serious > > > limitations. Is this still the binary we recommend to use ? > > > > Starting from 2.21.0, GUB uses the embeddable package for Python: > > https://docs.python.org/3.8/using/windows.html#the-embeddable-package > > > > This is official, so no "limitations" from our side. > > awesome. I assume that subprocess works normally on windows, so we can get rid > of the hack in lilylib.py I have no idea. I was satisfied after testing that it worked equally well as before (not using Windows in production since I-don't-know) Jonas signature.asc Description: This is a digitally signed message part
Re: LilyPond build for windows?
On Sun, Jun 21, 2020 at 12:07 PM Jonas Hahnfeld wrote: > > Am Samstag, den 20.06.2020, 20:25 +0200 schrieb Han-Wen Nienhuys: > > What is the status of our lilypond binary on windows? > > > > The GUB based binary used to include a hacked-together Python > > interpreter, which -due to being cross-compiled- had some serious > > limitations. Is this still the binary we recommend to use ? > > Starting from 2.21.0, GUB uses the embeddable package for Python: > https://docs.python.org/3.8/using/windows.html#the-embeddable-package > This is official, so no "limitations" from our side. awesome. I assume that subprocess works normally on windows, so we can get rid of the hack in lilylib.py -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: LilyPond build for windows?
Am Samstag, den 20.06.2020, 20:25 +0200 schrieb Han-Wen Nienhuys: > What is the status of our lilypond binary on windows? > > The GUB based binary used to include a hacked-together Python > interpreter, which -due to being cross-compiled- had some serious > limitations. Is this still the binary we recommend to use ? Starting from 2.21.0, GUB uses the embeddable package for Python: https://docs.python.org/3.8/using/windows.html#the-embeddable-package This is official, so no "limitations" from our side. The most severe limitation for Windows is that it's still 32-bit, so it crashes when compiling really large scores. I tried to get it to 64- bit, but Guile 1.8 simply doesn't work and crashes somewhere in the GC. This is no problem with Guile 2.2, see also my thread a few months back about my approach of native builds using few shell scripts. I've verified that this is able to compile larger scores that our official binaries fail on right now. Jonas signature.asc Description: This is a digitally signed message part
LilyPond build for windows?
What is the status of our lilypond binary on windows? The GUB based binary used to include a hacked-together Python interpreter, which -due to being cross-compiled- had some serious limitations. Is this still the binary we recommend to use ? -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: GUB lilypond build fails
>> Please cherry-pick 8067320145662554d85e59e6b9e6df3770f9e4a3 also; >> I'm going to submit fontconfig changes to gub that rely on the >> availability of this feature. > > Well, I am not happy with such fresh changes in the stable-2.20 > branch but a 2.20 that we don't manage to get through GUB is > pointless. So also done. Thanks! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
Werner LEMBERG writes: >>> cherry-picking 915799cad7118c39c89f564430093c0ad021dd9e from master >>> fixes that. >> >> Of course (change to Python 2.4 syntax). Done. > > Please cherry-pick 8067320145662554d85e59e6b9e6df3770f9e4a3 also; I'm > going to submit fontconfig changes to gub that rely on the > availability of this feature. Well, I am not happy with such fresh changes in the stable-2.20 branch but a 2.20 that we don't manage to get through GUB is pointless. So also done. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
>> cherry-picking 915799cad7118c39c89f564430093c0ad021dd9e from master >> fixes that. > > Of course (change to Python 2.4 syntax). Done. Please cherry-pick 8067320145662554d85e59e6b9e6df3770f9e4a3 also; I'm going to submit fontconfig changes to gub that rely on the availability of this feature. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
Knut Petersen writes: > On 30.12.18 19:31, Phil Holmes wrote: >> >> >> Success building from master. Thanks Werner. Will take me a time to >> sort out a build from the stable candidate, but it looks like we're >> on track. > > stable/2.20 currently will not build with gub. > > cherry-picking 915799cad7118c39c89f564430093c0ad021dd9e from master fixes > that. Of course (change to Python 2.4 syntax). Done. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
On 30.12.18 19:31, Phil Holmes wrote: Success building from master. Thanks Werner. Will take me a time to sort out a build from the stable candidate, but it looks like we're on track. stable/2.20 currently will not build with gub. cherry-picking 915799cad7118c39c89f564430093c0ad021dd9e from master fixes that. make lilypond took 4 hours on a core i7 with 4 core, 8 hyperthreads... i7-4790K: About 130 minutes for 'make lilypond' after an 'rm -rf target/*' Knut ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
"Phil Holmes" writes: > - Original Message - > From: "David Kastrup" > To: "Phil Holmes" > Cc: "Werner LEMBERG" ; > Sent: Sunday, December 30, 2018 6:46 PM > Subject: Re: GUB lilypond build fails > > >> "Phil Holmes" writes: >> >>> - Original Message - >>> From: "Phil Holmes" >>> To: "Werner LEMBERG" >>> Cc: ; >>> Sent: Sunday, December 30, 2018 12:29 PM >>> Subject: Re: GUB lilypond build fails >>> >>> >>>> >>>> The problem with "NewGub" would seem to be my issue. I've always >>>> made and uploaded GUB in a VM with a user gub and a directory called >>>> NewGub under that user's home directory. I'm currently trying to >>>> build from a user with a home directory called gubd and in a >>>> directory called GubDir. I do have a user called gub (it's where >>>> the VM lives) and could create a directory called NewGub and try to >>>> see if this works at this time. Watch this space. >>> >>> >>> Success building from master. Thanks Werner. Will take me a time to >>> sort out a build from the stable candidate, but it looks like we're on >>> track. >>> >>> make lilypond took 4 hours on a core i7 with 4 core, 8 hyperthreads... >> >> That does not say a lot without specifying the generation. I have in my >> laptop a >> >> model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz > > > core i7-2600 3.4GHz. About 8 years old Oh, 2nd generation like mine. It's not a mobile, but the difference in speed should actually be sort-of proportional to the clock frequency. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
- Original Message - From: "David Kastrup" To: "Phil Holmes" Cc: "Werner LEMBERG" ; Sent: Sunday, December 30, 2018 6:46 PM Subject: Re: GUB lilypond build fails "Phil Holmes" writes: - Original Message - From: "Phil Holmes" To: "Werner LEMBERG" Cc: ; Sent: Sunday, December 30, 2018 12:29 PM Subject: Re: GUB lilypond build fails The problem with "NewGub" would seem to be my issue. I've always made and uploaded GUB in a VM with a user gub and a directory called NewGub under that user's home directory. I'm currently trying to build from a user with a home directory called gubd and in a directory called GubDir. I do have a user called gub (it's where the VM lives) and could create a directory called NewGub and try to see if this works at this time. Watch this space. Success building from master. Thanks Werner. Will take me a time to sort out a build from the stable candidate, but it looks like we're on track. make lilypond took 4 hours on a core i7 with 4 core, 8 hyperthreads... That does not say a lot without specifying the generation. I have in my laptop a model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz core i7-2600 3.4GHz. About 8 years old -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
David Kastrup writes: > "Phil Holmes" writes: > >> - Original Message - >> From: "Phil Holmes" >> To: "Werner LEMBERG" >> Cc: ; >> Sent: Sunday, December 30, 2018 12:29 PM >> Subject: Re: GUB lilypond build fails >> >> >>> >>> The problem with "NewGub" would seem to be my issue. I've always >>> made and uploaded GUB in a VM with a user gub and a directory called >>> NewGub under that user's home directory. I'm currently trying to >>> build from a user with a home directory called gubd and in a >>> directory called GubDir. I do have a user called gub (it's where >>> the VM lives) and could create a directory called NewGub and try to >>> see if this works at this time. Watch this space. >> >> >> Success building from master. Thanks Werner. Will take me a time to >> sort out a build from the stable candidate, but it looks like we're on >> track. >> >> make lilypond took 4 hours on a core i7 with 4 core, 8 hyperthreads... > > That does not say a lot without specifying the generation. I have in my > laptop a > > model name: Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz > > which would formally meet this specification (I think it's pretty much > the lowest possible mobile CPU that would). Admittedly, the laptop is > not certified for the CPU's thermal design power and it's just since > last year or so since I caved and upgraded, but still it's considered > slow in comparison to today's usual horsepower. Over the CPU bragging I forgot the most important part of this information: YES Finally progress again. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
"Phil Holmes" writes: > - Original Message - > From: "Phil Holmes" > To: "Werner LEMBERG" > Cc: ; > Sent: Sunday, December 30, 2018 12:29 PM > Subject: Re: GUB lilypond build fails > > >> >> The problem with "NewGub" would seem to be my issue. I've always >> made and uploaded GUB in a VM with a user gub and a directory called >> NewGub under that user's home directory. I'm currently trying to >> build from a user with a home directory called gubd and in a >> directory called GubDir. I do have a user called gub (it's where >> the VM lives) and could create a directory called NewGub and try to >> see if this works at this time. Watch this space. > > > Success building from master. Thanks Werner. Will take me a time to > sort out a build from the stable candidate, but it looks like we're on > track. > > make lilypond took 4 hours on a core i7 with 4 core, 8 hyperthreads... That does not say a lot without specifying the generation. I have in my laptop a model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz which would formally meet this specification (I think it's pretty much the lowest possible mobile CPU that would). Admittedly, the laptop is not certified for the CPU's thermal design power and it's just since last year or so since I caved and upgraded, but still it's considered slow in comparison to today's usual horsepower. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
- Original Message - From: "Phil Holmes" To: "Werner LEMBERG" Cc: ; Sent: Sunday, December 30, 2018 12:29 PM Subject: Re: GUB lilypond build fails The problem with "NewGub" would seem to be my issue. I've always made and uploaded GUB in a VM with a user gub and a directory called NewGub under that user's home directory. I'm currently trying to build from a user with a home directory called gubd and in a directory called GubDir. I do have a user called gub (it's where the VM lives) and could create a directory called NewGub and try to see if this works at this time. Watch this space. Success building from master. Thanks Werner. Will take me a time to sort out a build from the stable candidate, but it looks like we're on track. make lilypond took 4 hours on a core i7 with 4 core, 8 hyperthreads... -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
"Phil Holmes" writes: > The problem with "NewGub" would seem to be my issue. I've always made > and uploaded GUB in a VM with a user gub and a directory called NewGub > under that user's home directory. I'm currently trying to build from > a user with a home directory called gubd and in a directory called > GubDir. I do have a user called gub (it's where the VM lives) and > could create a directory called NewGub and try to see if this works at > this time. Watch this space. Just as a strategy for would-be fixers: it is not really necessary to replace everything with relative paths: one can instead use an environment variable like $GUBHOME or whatever as an absolute path component. I think there are already environment variables described that need to be set for development/release work. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
- Original Message - From: "Werner LEMBERG" To: Cc: ; Sent: Saturday, December 29, 2018 8:42 PM Subject: Re: GUB lilypond build fails It now fails with a different file not found, but essentially still the same: [...] OK. If I try to locate the file we get: [...] Are these files displayable? You could try gv -nosafedir -nosafer foo.eps A curious other problem which I'd not remarked on before is that a little higher in the output I get: Operand stack: (/home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/fonts/otf/emmentaler-20.otf) (r) [...] Last OS error: No such file or directory Does this file exist? When I was building from git master (just a lily build, not GUB) I had the same error until I nuked the build directory and started from scratch. I haven't dived into doing partial builds at all... Right now I'm working on improving fontconfig support to not use fonts outside of gub. After this step I'm going to write a script to convert the absolute file paths in the `test-output' tarball to relative paths so that you don't need a `NewGub' user for a complete build. The problem with "NewGub" would seem to be my issue. I've always made and uploaded GUB in a VM with a user gub and a directory called NewGub under that user's home directory. I'm currently trying to build from a user with a home directory called gubd and in a directory called GubDir. I do have a user called gub (it's where the VM lives) and could create a directory called NewGub and try to see if this works at this time. Watch this space. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
> It now fails with a different file not found, but essentially still > the same: [...] OK. > If I try to locate the file we get: [...] Are these files displayable? You could try gv -nosafedir -nosafer foo.eps > A curious other problem which I'd not remarked on before is that a > little higher in the output I get: > > Operand stack: > (/home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/fonts/otf/emmentaler-20.otf) > (r) > [...] > Last OS error: No such file or directory Does this file exist? > When I was building from git master (just a lily build, not GUB) I > had the same error until I nuked the build directory and started > from scratch. I haven't dived into doing partial builds at all... Right now I'm working on improving fontconfig support to not use fonts outside of gub. After this step I'm going to write a script to convert the absolute file paths in the `test-output' tarball to relative paths so that you don't need a `NewGub' user for a complete build. Werner PS: Thanks for merging the pull request. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
- Original Message - From: "Werner LEMBERG" To: Cc: ; Sent: Monday, December 24, 2018 9:39 PM Subject: Re: GUB lilypond build fails It may be of note that an earlier (i.e. 6 months' earlier) successful run doesn't have the "invoking GS" line in its output. What does locate merge-rests-engraver say? Are files containing this name actually present for the old version? And what about newer version? Maybe a log file was created that contains more information? Werner It now failes with a different file not found, but essentially still the same: invoking gs -sDEVICE=png16m -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -slilypond-datadir=v2.19.64-1/share/lilypond/current -r101 -dAutoRotatePages=/None -dPrinted=false -sOutputFile=/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.19.64-1/rest-positioning.png -dNOSAFER -dEPSCrop -q -dNOPAUSE v2.19.64-1/rest-positioning.eps -c quit Traceback (most recent call last): File "/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/scripts/build/output-distance.py", line 1358, in ? main () If I try to locate the file we get: locate rest-positioning.eps /home/gubd/GubDir/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-master/input/regression/out-test/dynamics-rest-positioning.eps /home/gubd/GubDir/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-master/input/regression/out-test/rest-positioning.eps /home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.19.64-1/dynamics-rest-positioning.eps /home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.19.64-1/rest-positioning.eps /home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/dynamics-rest-positioning.eps /home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/rest-positioning.eps A curious other problem which I'd not remarked on before is that a little higher in the output I get: Operand stack: (/home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/fonts/otf/emmentaler-20.otf) (r) Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1983 1 3 %oparray_pop 1982 1 3 %oparray_pop --nostringval-- 1966 1 3 %oparray_pop 1852 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- Dictionary stack: --dict:1213/1684(ro)(G)-- --dict:0/20(G)-- --dict:82/200(L)-- Current allocation mode is local Last OS error: No such file or directory Current file position is 518 GPL Ghostscript 9.21: Unrecoverable error, exit code 1 When I was building from git master (just a lily build, not GUB) I had the same error until I nuked the build directory and started from scratch. Hmm. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
> It may be of note that an earlier (i.e. 6 months' earlier) > successful run doesn't have the "invoking GS" line in its output. What does locate merge-rests-engraver say? Are files containing this name actually present for the old version? And what about newer version? Maybe a log file was created that contains more information? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
> Now done and I get this: > > Error: /undefinedfilename in (v2.19.64-1/merge-rests-engraver.eps) > > [...] > > Which is true. The file doesn't exist. It should have come from > the test-output-distance.py, I think, but have no clue as to why > it's not there. How many processes do run in parallel on your system? Maybe lilypond's makefile setup is buggy (i.e., some missing dependencies), causing the use of `merge-rests-engraver.eps' before it is actually generated. Can you try to reduce the parallel jobs? Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
- Original Message -
From: "Phil Holmes"
To: "Werner LEMBERG"
Cc: ;
Sent: Monday, December 24, 2018 3:17 PM
Subject: Re: GUB lilypond build fails
- Original Message -
From: "Werner LEMBERG"
To:
Cc: ;
Sent: Monday, December 24, 2018 1:11 PM
Subject: Re: GUB lilypond build fails
This command seems to fail. Can you run it manually (with proper
values for $PATH, $GS_FONTPATH, and $GS_LIB) so that we can see its
output? Information about the environment variables should be
available in `lilypond-test.log'.
Any idea of what would be the proper values for those 3 environment
variables?
As mentioned above! A very long line in `lilypond-test.log' shows the
values. Looking into my
/home/wl/git/gub/target/linux-64/log/lilypond-test.log
file I see
+cd
/home/wl/git/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-master
\
&& ulimit -m 524288 \
&& ulimit -d 524288 \
&& ulimit -v 2097152 \
&&
LILYPOND_EXTERNAL_BINARY=/home/wl/git/gub/target/linux-64/root/usr/bin/lilypond
\
PATH=\
/home/wl/git/gub/target/tools/root/usr/bin\
:/home/wl/git/gub/target/linux-64/root/usr/bin\
:$PATH MALLOC_CHECK_=2 \
LD_LIBRARY_PATH=\
/home/wl/git/gub/target/tools/root/usr/lib\
:/home/wl/git/gub/target/linux-64/root/usr/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
\
GS_FONTPATH=\
/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/fonts\
:/home/wl/git/gub/target/linux-64/root/usr/share/gs/fonts \
GS_LIB=\
/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/Resource/Init\
:/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/Resource
\
FONTCONFIG_FILE=/home/wl/git/gub/target/linux-64/root/usr/etc/fonts/fonts.conf
\
FONTCONFIG_PATH=/home/wl/git/gub/target/linux-64/root/usr/etc/fonts \
make -j4 \
CPU_COUNT=2 \
MISSING_OPTIONAL=dblatex \
test
Put the environment variables after the last `&&' into a shell script
and execute the gs command in the right directory (given as the first
`cd' command).
Werner
I'll try a build of current master.
Same problem for me.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
--
Phil Holmes
- Original Message -
From: "Werner LEMBERG"
To:
Cc: ;
Sent: Monday, December 24, 2018 1:11 PM
Subject: Re: GUB lilypond build fails
This command seems to fail. Can you run it manually (with proper
values for $PATH, $GS_FONTPATH, and $GS_LIB) so that we can see its
output? Information about the environment variables should be
available in `lilypond-test.log'.
Any idea of what would be the proper values for those 3 environment
variables?
As mentioned above! A very long line in `lilypond-test.log' shows the
values. Looking into my
/home/wl/git/gub/target/linux-64/log/lilypond-test.log
file I see
+cd
/home/wl/git/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-master
\
&& ulimit -m 524288 \
&& ulimit -d 524288 \
&& ulimit -v 2097152 \
&&
LILYPOND_EXTERNAL_BINARY=/home/wl/git/gub/target/linux-64/root/usr/bin/lilypond
\
PATH=\
/home/wl/git/gub/target/tools/root/usr/bin\
:/home/wl/git/gub/target/linux-64/root/usr/bin\
:$PATH MALLOC_CHECK_=2 \
LD_LIBRARY_PATH=\
/home/wl/git/gub/target/tools/root/usr/lib\
:/home/wl/git/gub/target/linux-64/root/usr/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
\
GS_FONTPATH=\
/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/fonts\
:/home/wl/git/gub/target/linux-64/root/usr/share/gs/fonts \
GS_LIB=\
/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/Resource/Init\
:/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/Resource
\
FONTCONFIG_FILE=/home/wl/git/gub/target/linux-64/root/usr/etc/fonts/fonts.conf
\
FONTCONFIG_PATH=/home/wl/git/gub/target/linux-64/root/usr/etc/fonts \
make -j4 \
CPU_COUNT=2 \
MISSING_OPTIONAL=dblatex \
test
Put the environment variables after the last `&&' into a shell script
and execute the gs command in the right directory (given as the first
`cd' command).
Werner
It may be of note that an earlier (i.e. 6 months' earlier) successful run
doesn't have the "invoking GS" line in its output. I'll paste the early
good run below and the later bad run below that. I do have one thought now,
though. I'm running against release/unstable. That's probably not been
updated with some fixes, I'll try a build of current master.
Good build:
1 below threshold
3755 unchanged
mkdir /home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1
mkdir
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.81-1
v2.19.81-1/parallelmusic-partial.profile ->
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.81-1/parallelmusic-partial.profile
mkdir
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.82-1
v2.19.82-1/parallelmusic-partial.profile ->
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.82-1/parallelmusic-partial.profile
v2.19.81-1/parallelmusic-partial.log ->
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.81-1/parallelmusic-partial.log
v2.19.82-1/parallelmusic-partial.log ->
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.82-1/parallelmusic-partial.log
v2.19.81-1/make-relative.log ->
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.81-1/make-relative.log
v2.19.82-1/make-relative.log ->
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.82-1/make-relative.log
v2.19.81-1/tree.gittxt ->
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.81-1/tree.gittxt
v2.19.82-1/tree.gittxt ->
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/v2.19.82-1/tree.gittxt
writing
"/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1/index.txt"
tar --strip-component=3 -C
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1-unpack/v2.19.81-1 -xjf
regtests/lilypond-2.19.81-1.test-output.tar.bz2
tar --strip-component=3 -C
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1-unpack/v2.19.82-1 -xjf
uploads/lilypond-2.19.82-1.test-output.tar.bz2
cd /home/gub/NewGub/gub/uploads/webtest/v2.19.82-1-unpack && python
/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/scripts/build/output-distance.py
--create-images --output-dir
/home/gub/NewGub/gub/uploads/webtest/v2.19.82-1/compare-v2.19.81-1 --local-datadir
v2.19.81-1 v2.19.82-1
rm -rf /home/gub/NewGub/gub/uploads/webtest/v2.19.82-1-unpack
make[3]: Leaving directory `/home/gub/NewGub/gub'
make[2]: Leaving directory `/home/gub/NewGub/gub'
test rule
Failed build:
1251 below threshold
1161 unchanged
mkdir /home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1
mkdir
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.21.0-1
mkdir
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.19.64-1
v2.19.64-1/merge-rests-engraver.ly -&g
Re: GUB lilypond build fails
-- Phil Holmes - Original Message - From: "Werner LEMBERG" To: Cc: ; Sent: Monday, December 24, 2018 1:11 PM Subject: Re: GUB lilypond build fails This command seems to fail. Can you run it manually (with proper values for $PATH, $GS_FONTPATH, and $GS_LIB) so that we can see its output? Information about the environment variables should be available in `lilypond-test.log'. Any idea of what would be the proper values for those 3 environment variables? As mentioned above! A very long line in `lilypond-test.log' shows the values. Looking into my /home/wl/git/gub/target/linux-64/log/lilypond-test.log Sorry. Now done and I get this: gubd@ubuntu12:~$ ./gs_test.sh Error: /undefinedfilename in (v2.19.64-1/merge-rests-engraver.eps) Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push Dictionary stack: --dict:1212/1684(ro)(G)-- --dict:0/20(G)-- --dict:78/200(L)-- Current allocation mode is local Last OS error: No such file or directory GPL Ghostscript 9.21: Unrecoverable error, exit code 1 Which is true. The file doesn't exist. It should have come from the test-output-distance.py, I think, but have no clue as to why it's not there. I'd appreciate anyone's further insight as to what might have happened. I might just try running GUB again in case it was a glitch. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
>> This command seems to fail. Can you run it manually (with proper
>> values for $PATH, $GS_FONTPATH, and $GS_LIB) so that we can see its
>> output? Information about the environment variables should be
>> available in `lilypond-test.log'.
>
> Any idea of what would be the proper values for those 3 environment
> variables?
As mentioned above! A very long line in `lilypond-test.log' shows the
values. Looking into my
/home/wl/git/gub/target/linux-64/log/lilypond-test.log
file I see
+cd
/home/wl/git/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-master
\
&& ulimit -m 524288 \
&& ulimit -d 524288 \
&& ulimit -v 2097152 \
&&
LILYPOND_EXTERNAL_BINARY=/home/wl/git/gub/target/linux-64/root/usr/bin/lilypond
\
PATH=\
/home/wl/git/gub/target/tools/root/usr/bin\
:/home/wl/git/gub/target/linux-64/root/usr/bin\
:$PATH MALLOC_CHECK_=2 \
LD_LIBRARY_PATH=\
/home/wl/git/gub/target/tools/root/usr/lib\
:/home/wl/git/gub/target/linux-64/root/usr/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
\
GS_FONTPATH=\
/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/fonts\
:/home/wl/git/gub/target/linux-64/root/usr/share/gs/fonts \
GS_LIB=\
/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/Resource/Init\
:/home/wl/git/gub/target/linux-64/root/usr/share/ghostscript/9.21/Resource \
FONTCONFIG_FILE=/home/wl/git/gub/target/linux-64/root/usr/etc/fonts/fonts.conf \
FONTCONFIG_PATH=/home/wl/git/gub/target/linux-64/root/usr/etc/fonts \
make -j4 \
CPU_COUNT=2 \
MISSING_OPTIONAL=dblatex \
test
Put the environment variables after the last `&&' into a shell script
and execute the gs command in the right directory (given as the first
`cd' command).
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
- Original Message - From: "Werner LEMBERG" To: Cc: ; ; Sent: Sunday, December 23, 2018 11:19 PM Subject: Re: GUB lilypond build fails Almost completed a GUB build today, building against release/unstable. Unfortunately it eventually failed with the errors below. Can anyone suggest what ids going wrong? invoking gs -sDEVICE=png16m \ -dGraphicsAlphaBits=4 \ -dTextAlphaBits=4 \ -slilypond-datadir=v2.19.64-1/share/lilypond/current \ -r101 \ -dAutoRotatePages=/None \ -sOutputFile=/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.19.64-1/merge-rests-engraver.png \ -dNOSAFER \ -dEPSCrop \ -q \ -dNOPAUSE \ v2.19.64-1/merge-rests-engraver.eps -c quit This command seems to fail. Can you run it manually (with proper values for $PATH, $GS_FONTPATH, and $GS_LIB) so that we can see its output? Information about the environment variables should be available in `lilypond-test.log'. Werner Any idea of what would be the proper values for those 3 environment variables? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
> Almost completed a GUB build today, building against > release/unstable. Unfortunately it eventually failed with the errors > below. Can anyone suggest what ids going wrong? > > invoking gs -sDEVICE=png16m \ > -dGraphicsAlphaBits=4 \ > -dTextAlphaBits=4 \ > -slilypond-datadir=v2.19.64-1/share/lilypond/current \ > -r101 \ > -dAutoRotatePages=/None \ > > -sOutputFile=/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.19.64-1/merge-rests-engraver.png > \ > -dNOSAFER \ > -dEPSCrop \ > -q \ > -dNOPAUSE \ > v2.19.64-1/merge-rests-engraver.eps > -c quit This command seems to fail. Can you run it manually (with proper values for $PATH, $GS_FONTPATH, and $GS_LIB) so that we can see its output? Information about the environment variables should be available in `lilypond-test.log'. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
Almost completed a GUB build today, building against release/unstable.
Unfortunately it eventually failed with the errors below. Can anyone
suggest what ids going wrong?
mkdir /home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1
mkdir
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.21.0-1
mkdir
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.19.64-1
v2.19.64-1/merge-rests-engraver.ly ->
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.19.64-1/merge-rests-engraver.ly
v2.21.0-1/merge-rests-engraver.ly ->
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.21.0-1/merge-rests-engraver.ly
invoking
gs -sDEVICE=png16m -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -slilypond-datadir=v2.19.64-1/share/lilypond/current
-r101 -dAutoRotatePages=/None -sOutputFile=/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1/v2.19.64-1/merge-rests-engraver.png
-dNOSAFER -dEPSCrop -q -dNOPAUSE v2.19.64-1/merge-rests-engraver.eps -c
quit
Traceback (most recent call last):
File
"/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py",
line 1349, in ?
main ()
File
"/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py",
line 1346, in main
compare_tree_pairs (zip (args[0::2], args[1::2]), out, options.threshold)
File
"/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py",
line 1061, in compare_tree_pairs
data.create_html_result_page (dest_dir, threshold)
File
"/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py",
line 1043, in create_html_result_page
link.link_files_for_html (dest_dir)
File
"/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py",
line 660, in link_files_for_html
to_compare = self.create_images (dest_dir)
File
"/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py",
line 650, in create_images
system (cmd)
File
"/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py",
line 1091, in system
assert stat == 0
AssertionError
tar --strip-component=3 -C
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.19.64-1 -xjf
regtests/lilypond-2.19.64-1.test-output.tar.bz2
tar --strip-component=3 -C
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1 -xjf
uploads/lilypond-2.21.0-1.test-output.tar.bz2
cd /home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1-unpack && python
/home/gubd/GubDir/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/output-distance.py
--create-images --output-dir
/home/gubd/GubDir/gub/uploads/webtest/v2.21.0-1/compare-v2.19.64-1 --local-datadir
v2.19.64-1 v2.21.0-1
Traceback (most recent call last):
File "test-lily/rsync-test.py", line 204, in ?
main ()
File "test-lily/rsync-test.py", line 198, in main
compare_test_info (options)
File "test-lily/rsync-test.py", line 169, in compare_test_info
compare_test_tarballs (options, versions_found[-3:])
File "test-lily/rsync-test.py", line 119, in compare_test_tarballs
system (cmd)
File "test-lily/rsync-test.py", line 77, in system
raise Exception ('fail')
Exception: fail
make[3]: *** [unlocked-test-export] Error 1
make[3]: Leaving directory `/home/gubd/GubDir/gub'
make[2]: *** [cached-test-export] Error 2
make[2]: Leaving directory `/home/gubd/GubDir/gub'
make[1]: *** [test-export] Error 2
make[1]: Leaving directory `/home/gubd/GubDir/gub'
make: *** [lilypond] Error 2
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
Werner LEMBERG writes: >> So it would be really _urgent_ to get GUB advanced to a recent >> version of Python 2 in all supported platforms > > Yes. > >> (and I think we can delist the PPC platform support by now): > > What's exactly the reason for this? Considerable resources in compilation and maintenance time without an obvious user? >> But at least PPC seems reasonably safe to retire, and possibly >> FreeBSD if it helps. > > AFAIK, it doesn't help since the requirements are the same. Whoever does the human GUB work (in this case moving Python to newer versions) gets to decide this I guess. Whoever does it is in my book free to decide to drop it after looking at it as thoroughly or casually as they consider fit. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
> So it would be really _urgent_ to get GUB advanced to a recent > version of Python 2 in all supported platforms Yes. > (and I think we can delist the PPC platform support by now): What's exactly the reason for this? > But at least PPC seems reasonably safe to retire, and possibly > FreeBSD if it helps. AFAIK, it doesn't help since the requirements are the same. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
Andrew Bernard writes: > Hi All, > > I am new to lilypond dev. work. My intention may be naive, but I am wanting > to do the work to uplift gub and lilypond to python 3. Am I premature, or > foolish, or misguided? I did have some encouraging email about this > previously, but I just wanted to check before I dive in and spend large > amounts of time, especially re GUB. I have yesterday asked Masamichi-san to take a look at our current GUB problems but it would appear that Werner found and fixed the source of the current roadblock. Now it sounded like Masamichi-san was currently rather short of time for this, so it would make sense that now, since the immediate problem appears to be solved, you take a look at this instead with a perspective of a Python 3 migration eventually. So I did some "git blame" searching and it would appear that the Python 2.5 "ism" was introduced with commit commit 7b07440da921d979ab492fd284b6198152a8020c Author: Alexander Myltsev AuthorDate: Thu Jun 2 11:19:07 2016 +0300 Commit: James Lowe CommitDate: Sat Jun 16 10:59:08 2018 +0100 musicxml2ly: handle hidden time signatures. Now I don't really feel that we can indeed pass any blame for not being aware of having to use syntax for an ancient rather than an antique version of Python. And we apparently don't have the manpower in place to figure out what went wrong: this put our release process to a halt for almost half a year. So it would be really _urgent_ to get GUB advanced to a recent version of Python 2 in all supported platforms (and I think we can delist the PPC platform support by now): the current Python 2 requirement is obvious, the Python 2.4 requirement not. Moving to a current Python 2 version should be doable without changing the LilyPond source code: that's a pure GUB job, though one that might be bothersome on some platforms. Decommissioning the PPC platforms would likely make this easier, and I don't think we really have active users there. Masamichi-san also suggested stopping FreeBSD support (I don't know if there is much of an indication the binary installation from us is used rather than compiling themselves, and supposedly they can run Linux binaries though the runtime environment may be troublesome) and Windows 32-bit support. I am not sure whether there aren't people running 32-bit Windows binaries in VMs though. But at least PPC seems reasonably safe to retire, and possibly FreeBSD if it helps. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
Hi Carl, I'm on the case. This is the sort of work I can do. I have never been able to get into the groove of lilypond internals for some reason, but this type of system building tool is right up my alley. Andrew On Mon, 17 Dec 2018 at 14:53, Carl Sorensen wrote: > > GUB provides us a pretty wonderful functionality -- it builds for Linux, > Windows, and OSX, so we can provide pre-built binaries for all of those > platforms. > > I think that you need to investigate and make your own decision. Spend a > bit of time trying to get to understand GUB. Try making the changes you > want to make. See how it works. See if you can wrap your arms around it. > If you can become an expert in GUB, you'll be an invaluable asset to the > Lilypond development team. Personally, I'd love to have you do that! > > ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
Carl Sorensen writes: > On 12/16/18, 6:42 PM, "lilypond-devel on behalf of Andrew Bernard" > andrew.bern...@gmail.com> wrote: > > Hi All, > > I am new to lilypond dev. work. My intention may be naive, but I am > wanting > to do the work to uplift gub and lilypond to python 3. Am I premature, or > foolish, or misguided? I did have some encouraging email about this > previously, but I just wanted to check before I dive in and spend large > amounts of time, especially re GUB. > > > I'm quite certain you're not premature. > > I don't know if you're foolish or misguided. > > GUB is a lot old, and a little bit (or maybe more) fragile. It's > primary developer (Jan) has decided he doesn't want to work more on > it. He'd rather pursue a different method of doing the > cross-compilation. Nix will not build Windows binaries, so it's not like his current pursuits will lead to a replacement of what GUB does for us. We don't really have any workable alternative on the horizon. But I do think we can retire at least the PPC platforms. And I don't think the FreeBSD compilations are used a lot either. > I think that you need to investigate and make your own decision. > Spend a bit of time trying to get to understand GUB. Try making the > changes you want to make. See how it works. See if you can wrap your > arms around it. If you can become an expert in GUB, you'll be an > invaluable asset to the Lilypond development team. Personally, I'd > love to have you do that! A Python 3 migration would be useful but of course requires some GUB lifting. It definitely would be a sizable amount of work. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
On 12/16/18, 6:42 PM, "lilypond-devel on behalf of Andrew Bernard" wrote: Hi All, I am new to lilypond dev. work. My intention may be naive, but I am wanting to do the work to uplift gub and lilypond to python 3. Am I premature, or foolish, or misguided? I did have some encouraging email about this previously, but I just wanted to check before I dive in and spend large amounts of time, especially re GUB. I'm quite certain you're not premature. I don't know if you're foolish or misguided. GUB is a lot old, and a little bit (or maybe more) fragile. It's primary developer (Jan) has decided he doesn't want to work more on it. He'd rather pursue a different method of doing the cross-compilation. GUB provides us a pretty wonderful functionality -- it builds for Linux, Windows, and OSX, so we can provide pre-built binaries for all of those platforms. I think that you need to investigate and make your own decision. Spend a bit of time trying to get to understand GUB. Try making the changes you want to make. See how it works. See if you can wrap your arms around it. If you can become an expert in GUB, you'll be an invaluable asset to the Lilypond development team. Personally, I'd love to have you do that! Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
Hi All, I am new to lilypond dev. work. My intention may be naive, but I am wanting to do the work to uplift gub and lilypond to python 3. Am I premature, or foolish, or misguided? I did have some encouraging email about this previously, but I just wanted to check before I dive in and spend large amounts of time, especially re GUB. Andrew On Mon, 17 Dec 2018 at 12:16, Carl Sorensen wrote: > > > On 12/16/18, 4:38 PM, "lilypond-devel on behalf of Werner LEMBERG" > > wrote: > > > >I think you have the same issue me and others had. You don't see > >it in the tail below, but if you open the lilypond.log file > >you'll see a python command failing to generate a file because > >GUB python is 2.4 while lilypond python code uses if statements. > >It's discussed in one of the pull requests on GitHub. > > I took to liberty to `hotfix' this issue in the lilypond git > repository: There was a single place in `musicexp.py' that used 2.5 > syntax, which I've just changed back to 2.4 syntax in `staging'. > > Thank you, Werner! That is an excellent solution. > > We will still want to look into a long-term fix in the build/distribution > system. But getting it to work right now is really important. > > Thanks, > > > Carl > > > ___ > lilypond-devel mailing list > lilypond-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
On 12/16/18, 4:38 PM, "lilypond-devel on behalf of Werner LEMBERG" wrote: >I think you have the same issue me and others had. You don't see >it in the tail below, but if you open the lilypond.log file >you'll see a python command failing to generate a file because >GUB python is 2.4 while lilypond python code uses if statements. >It's discussed in one of the pull requests on GitHub. I took to liberty to `hotfix' this issue in the lilypond git repository: There was a single place in `musicexp.py' that used 2.5 syntax, which I've just changed back to 2.4 syntax in `staging'. Thank you, Werner! That is an excellent solution. We will still want to look into a long-term fix in the build/distribution system. But getting it to work right now is really important. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
> lilypond should now build with gub as soon as this commit goes to
> `master'.
To be more precise: I can build lilypond with gub on my openSuSE Leap
42.3 GNU/Linux box.[*]
I use the attached patches for gub (relative to HEAD), which are based
on
https://github.com/gperciva/gub/pull/7
plus some other changes that I'm going to submit as soon as my gub
build completes.
Werner
[*] The nasty `ar' bug I've reported some time ago is still present
but I can circumvent the issue. IMHO this is nothing gub should
take care of.
diff --git a/arbora.make b/arbora.make
index 1754d77d..8b9250ba 100644
--- a/arbora.make
+++ b/arbora.make
@@ -45,10 +45,10 @@ arbora-installers:
$(foreach p, $(PLATFORMS), $(call INVOKE_INSTALLER_BUILDER,$(p)) $(INSTALL_PACKAGE) &&) true #
nsis:
- bin/gub tools::nsis
+ $(GUB) tools::nsis
update-versions:
- python gub/versiondb.py --no-sources --version-db=versiondb/arbora.versions --download --platforms="mingw" --url=http://lilypond.org/blog/janneke/software/arbora
+ $(PYTHON) gub/versiondb.py --no-sources --version-db=versiondb/arbora.versions --download --platforms="mingw" --url=http://lilypond.org/blog/janneke/software/arbora
print-success:
@echo "success!!"
diff --git a/bin/gib b/bin/gib
index 0a7ccf39..91d98b64 100755
--- a/bin/gib
+++ b/bin/gib
@@ -102,6 +102,11 @@ Examples:
(options, args) = p.parse_args ()
+if not args:
+gub_log.error ('error: nothing to do\n')
+p.print_help ()
+sys.exit (2)
+
return (options, args)
def check_installer (installer, options, args):
diff --git a/bin/gub b/bin/gub
index dd4b3763..261e7f90 100755
--- a/bin/gub
+++ b/bin/gub
@@ -280,7 +280,7 @@ def environment_sanity (settings):
if os.path.exists (environment_file):
environment = dict (pickle.loads (open (environment_file, 'rb').read ()))
# expand any ~ in the PATH
-os.environ['PATH'] = ":".join( map( lambda(x):os.path.expanduser(x),
+os.environ['PATH'] = ":".join( map( os.path.expanduser,
os.environ['PATH'].split(':')))
differ = []
for key in list (misc.uniq (sorted (environment.keys ()
diff --git a/denemo.make b/denemo.make
index 60508814..b1343988 100644
--- a/denemo.make
+++ b/denemo.make
@@ -52,10 +52,10 @@ denemo-installers:
$(foreach p, $(PLATFORMS), $(call INVOKE_INSTALLER_BUILDER,$(p)) $(INSTALL_PACKAGE) &&) true #
nsis:
- bin/gub tools::nsis
+ $(GUB) tools::nsis
update-versions:
- python gub/versiondb.py --no-sources --version-db=versiondb/denemo.versions --download --platforms="mingw" --url=http://lilypond.org/blog/janneke/software/denemo
+ $(PYTHON) gub/versiondb.py --no-sources --version-db=versiondb/denemo.versions --download --platforms="mingw" --url=http://lilypond.org/blog/janneke/software/denemo
print-success:
@echo "success!!"
diff --git a/gub/dependency.py b/gub/dependency.py
index 6518102e..3220d8ed 100644
--- a/gub/dependency.py
+++ b/gub/dependency.py
@@ -35,7 +35,7 @@ def get_build_from_file (platform, file_name, name):
and (not cls or issubclass (cls, target.AutoBuild))):
cls = misc.most_significant_in_dict (module.__dict__, class_name.replace ('tools32', 'tools'), '__')
if ((platform == 'tools' or platform == 'tools32')
-and (issubclass (cls, target.AutoBuild)
+and (not cls or issubclass (cls, target.AutoBuild)
and not issubclass (cls, tools.AutoBuild)
and not issubclass (cls, tools32.AutoBuild))):
cls = None
diff --git a/gub/specs/autoconf.py b/gub/specs/autoconf.py
index 6435d892..0c7b200f 100644
--- a/gub/specs/autoconf.py
+++ b/gub/specs/autoconf.py
@@ -7,3 +7,6 @@ class Autoconf__tools (tools.AutoBuild):
'm4',
'perl',
]
+# prevent execution of Emacs to build .elc files
+configure_variables = (tools.AutoBuild.configure_variables
+ + ' EMACS=false')
diff --git a/gub/specs/darwin/cross/gcc.py b/gub/specs/darwin/cross/gcc.py
index a0c349b0..bca7923e 100644
--- a/gub/specs/darwin/cross/gcc.py
+++ b/gub/specs/darwin/cross/gcc.py
@@ -3,6 +3,7 @@ import os
from gub.specs.cross import gcc as cross_gcc
from gub import loggedos
from gub import cross
+from gub import misc
class Gcc__darwin (cross_gcc.Gcc):
dependencies = ['tools::gmp', 'tools::mpfr', 'tools::mpc', 'odcctools']
@@ -13,6 +14,10 @@ class Gcc__darwin (cross_gcc.Gcc):
configure_flags = (cross_gcc.Gcc.configure_flags
+ ' --disable-libcilkrts'
)
+configure_variables = (cross_gcc.Gcc.configure_variables
+ + misc.join_lines ('''
+MAKEINFO=no
+'''))
def languages (self):
# objective-c is used for quartz's Carbon/Carbon.h in pango, gtk+
return cross_gcc.Gcc.languages (self) + ['objc', 'obj-c++']
diff --git a/gub/specs/freebsd/cross/gcc.py b/gub/specs/freebsd/cross/gcc.py
index 663a8bd3..4b25d366 100644
---
Re: GUB lilypond build fails
>I think you have the same issue me and others had. You don't see >it in the tail below, but if you open the lilypond.log file >you'll see a python command failing to generate a file because >GUB python is 2.4 while lilypond python code uses if statements. >It's discussed in one of the pull requests on GitHub. I took to liberty to `hotfix' this issue in the lilypond git repository: There was a single place in `musicexp.py' that used 2.5 syntax, which I've just changed back to 2.4 syntax in `staging'. lilypond should now build with gub as soon as this commit goes to `master'. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GUB lilypond build fails
Hi Andrew I think you have the same issue me and others had. You don't see it in the tail below, but if you open the lilypond.log file you'll see a python command failing to generate a file because GUB python is 2.4 while lilypond python code uses if statements. It's discussed in one of the pull requests on GitHub. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
GUB lilypond build fails
I am setup with lilydev 0.3, the latest release. I have installed gub from github, current master. Gub bootstrap runs to completion with no errors. Attempting to make lilypond, it fails as follows: $ bin/gub lilypond building package: linux-64::lilypond *** Stage: download (lilypond, linux-64) *** Stage: untar (lilypond, linux-64) *** Stage: patch (lilypond, linux-64) *** Stage: autoupdate (lilypond, linux-64) *** Stage: configure (lilypond, linux-64) *** Stage: compile (lilypond, linux-64) *** Stage: install (lilypond, linux-64) Command barfed: cd /u01/work/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-master && make TARGET_PYTHON=/usr/bin/python DESTDIR=/u01/work/gub/target/linux-64/install/lilypond-2.21.0-root install Tail of target/linux-64/log/lilypond.log make[1]: *** [local-install-outfiles] Error 1 make[1]: Leaving directory `/u01/work/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-master/python' make: *** [install] Error 2 Command barfed: cd /u01/work/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-master && make TARGET_PYTHON=/usr/bin/python DESTDIR=/u01/work/gub/target/linux-64/install/lilypond-2.21.0-root install Tail of target/linux-64/log/lilypond.log *** Failed target: linux-64::lilypond What step have I missed? Andrew ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build: version
On Mar 2, 2015, at 09:03 , Masamichi HOSODA truer...@sea.plala.or.jp wrote: darwin-x86: Untested My Intel Mac environment was quite a temporary. Now, I don't have it. It runs without crashing on 10.10.2. Thank you for reporting. I'm happy to hear it. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build: version
On Mar 2, 2015, at 09:03 , Masamichi HOSODA truer...@sea.plala.or.jp wrote: darwin-x86: Untested My Intel Mac environment was quite a temporary. Now, I don't have it. It runs without crashing on 10.10.2. — Dan ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build: version
Upload is now proceeding. Takes about 5 hours and slows internet access for the house to a crawl :-( Thank you for uploading official binaries. I've tested the binaries in my environments. The results are as follows. linux-x86: Ubuntu 14.04 LTS x86_64 (with 32bit libs) Fine linux-64: Ubuntu 14.04 LTS x86_64 Fine linux-ppc: Debian wheezy PowerPC (on qemu-system-ppc on Windows 8.1) Fine freebsd-x86: FreeBSD 10.1-RELEASE i386 (with compat libs) Fine freebsd-64: FreeBSD 10.1-RELEASE amd64 (with compat libs) Fine mingw (Windows): Windows 8.1 64bit Fine And, this issue http://code.google.com/p/lilypond/issues/detail?id=431 has been fixed. Because GUB's binutils has been updated to 2.25. darwin-x86: Untested My Intel Mac environment was quite a temporary. Now, I don't have it. darwin-ppc: Untested I couldn't prepare PowerPC Mac. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build: version
Keith OHara k-ohara5...@oco.net writes: Phil Holmes mail at philholmes.net writes: I completed a full GUB build of lilypond yesterday That's very good news. I was beginning to worry. Well, it's been 5 months. It's clear that our current maintainership of GUB is not working out. Basically the model is Phil is running it, so let him keep it running. Now it's a great testament to GUB's qualities that after initial setup it kept churning out releases for years without anybody knowing all too much what they were doing. It's great that Masamichi Hosoda turned up and made the necessary changes to GUB and then helped Phil along, but we need to get GUB a bit more unstuck than it currently is. I'll be moving its development to Savannah soonish and will try getting it some traction as a general GNU endeavor: after all, most projects delivering Windows executables go through a lot more pain than we do: the Windows ports of Git, Mingw, and a number of others are multi-person efforts usually trailing significantly behind the native compilations, and they require a lot more know-how and work to produce than ours as long as GUB is in working state. And the GUB problems we were having just now were not at all LilyPond related: with a generally maintained GUB, all of the required work (namely updating g++) would likely have been done by someone else by the time we needed it. Thanks for taking the time to work through the problems. A lot of those thanks belong to Masamichi Hosoda. For me, Phil's most admirable accomplishment is not setting fire to the pile basically dropped at his feet but sticking around until help arrived for untangling it. Stuff like that is quite mentally draining and unthankful. I was elated about the improving news, and I also was elated that when I finally saw that the upload had succeeded, I noticed at the same time already about a dozen issues getting verified as fixed and closed. We are still operative! -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilypond build: version
I completed a full GUB build of lilypond yesterday (it took 5 hours on my superfast machine). However, at present I can't upload it: I'm investigating but can't guarantee a solution quickly. I would like to be able to keep the package I've built available for upload as 2.19.16. I would therefore like to bump the development version to 2.19.17, even without 2.19.16 yet available online. If you object, please shout quickly: say in the next couple of hours. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build: version
- Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Sunday, March 01, 2015 11:10 AM Subject: Re: Lilypond build: version Phil Holmes m...@philholmes.net writes: I completed a full GUB build of lilypond yesterday (it took 5 hours on my superfast machine). Sounds about par for the course. When it's running right, it should be about an hour, so I hope this is just a start-up with lots of changes time. Good luck and success finding the culprit for the upload problem! History repeating itself: https://lists.gnu.org/archive/html/lilypond-devel/2012-08/msg00717.html Upload is now proceeding. Takes about 5 hours and slows internet access for the house to a crawl :-( -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build: version
- Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Sunday, March 01, 2015 11:40 AM Subject: Re: Lilypond build: version Phil Holmes m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Sunday, March 01, 2015 11:10 AM Subject: Re: Lilypond build: version Phil Holmes m...@philholmes.net writes: I completed a full GUB build of lilypond yesterday (it took 5 hours on my superfast machine). Sounds about par for the course. When it's running right, it should be about an hour, so I hope this is just a start-up with lots of changes time. Good luck and success finding the culprit for the upload problem! History repeating itself: https://lists.gnu.org/archive/html/lilypond-devel/2012-08/msg00717.html Upload is now proceeding. Takes about 5 hours and slows internet access for the house to a crawl :-( Try finding a way to throttle the upload rate at about 90% of your upload capacity (some environment variables for the upload program perhaps? Or some parameters one can set in the VM or VM kernel?). Internet access is almost exclusively download capacity, so the main reason the internet access for the house is at a crawl is that the upload-direction parts of the communication required for downloading take too long to get through even though they take up very little bandwidth. If you manage to throttle the upload rate just a bit, the upload will not take much longer while the internet access for the house will become unstuck for typical use cases. -- David Kastrup I did look at throttling the upload speed when I first started running the build, but failed. I realise it's the TCP ACKs that are slowing download speeds. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build: version
Phil Holmes m...@philholmes.net writes: - Original Message - From: David Kastrup d...@gnu.org To: Phil Holmes m...@philholmes.net Cc: lilypond-devel@gnu.org Sent: Sunday, March 01, 2015 11:10 AM Subject: Re: Lilypond build: version Phil Holmes m...@philholmes.net writes: I completed a full GUB build of lilypond yesterday (it took 5 hours on my superfast machine). Sounds about par for the course. When it's running right, it should be about an hour, so I hope this is just a start-up with lots of changes time. Good luck and success finding the culprit for the upload problem! History repeating itself: https://lists.gnu.org/archive/html/lilypond-devel/2012-08/msg00717.html Upload is now proceeding. Takes about 5 hours and slows internet access for the house to a crawl :-( Try finding a way to throttle the upload rate at about 90% of your upload capacity (some environment variables for the upload program perhaps? Or some parameters one can set in the VM or VM kernel?). Internet access is almost exclusively download capacity, so the main reason the internet access for the house is at a crawl is that the upload-direction parts of the communication required for downloading take too long to get through even though they take up very little bandwidth. If you manage to throttle the upload rate just a bit, the upload will not take much longer while the internet access for the house will become unstuck for typical use cases. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build: version
Phil Holmes m...@philholmes.net writes: I completed a full GUB build of lilypond yesterday (it took 5 hours on my superfast machine). Sounds about par for the course. However, at present I can't upload it: I'm investigating but can't guarantee a solution quickly. I would like to be able to keep the package I've built available for upload as 2.19.16. I would therefore like to bump the development version to 2.19.17, even without 2.19.16 yet available online. If you object, please shout quickly: say in the next couple of hours. I don't see a problem with that: in the absolutely worst case, we are better off with a missing version (or even a defective one we need to pull for sanity) than with a double one. We are talking about developer releases here after all. Good luck and success finding the culprit for the upload problem! -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build: version
Phil Holmes mail at philholmes.net writes: I completed a full GUB build of lilypond yesterday That's very good news. I was beginning to worry. Thanks for taking the time to work through the problems. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Lilypond build dependencies
Hello all, I'm trying to build Lilypond from git-HEAD source for the first time in a while and running into some curiosities from the ./configure script. This is on Ubuntu 13.10. First of all: ./configure requests a number of build dependencies that are not listed on the pages here: http://lilypond.org/doc/v2.17/Documentation/contributor/requirements-for-running-lilypond http://lilypond.org/doc/v2.17/Documentation/contributor/requirements-for-compiling-lilypond http://lilypond.org/doc/v2.17/Documentation/contributor/requirements-for-building-documentation ... which included dblatex, epsf.tex (contained in texlive-generic-recommended) and lh (contained in texlive-lang-cyrillic). At a guess, perhaps these would typically be installed as recommended by the packages that are listed, so anyone (like me) installing _only_ what's listed (and its strict dependencies) will come up against this issue. I'm sure that if I'd just run apt-get build-dep lilypond all would have been fine, but the listed dependencies are the first thing one reads. The blocker to building is the metapost version currently in Ubuntu 13.10. ./configure reports: ERROR: Please install required programs: mpost (due to a bug in metapost, versions 1.600 = x 1.803 are not supported; installed: 1.802) What's the problem here, and is it possible to work around (i.e. tell ./configure I don't care, go ahead and accept working with 1.802) or is the bug sufficiently show-stopping that nothing can be done bar install the updated metapost? Thanks best wishes, -- Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build dependencies
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: What's the problem here, and is it possible to work around (i.e. tell ./configure I don't care, go ahead and accept working with 1.802) or is the bug sufficiently show-stopping that nothing can be done bar install the updated metapost? It's a showstopper. Most of the flags will look absurd, and things like the treble clef as well. Maybe you can use tlmgr for updating your Metapost. No idea. Or complain to Ubuntu that they still have not updated their TeXlive. Maybe downgrading Metapost is an option if you can't figure out how to upgrade. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build dependencies
On 05/10/13 19:01, David Kastrup wrote: Maybe you can use tlmgr for updating your Metapost. Well, you saw the error I encountered when trying to use tlmgr to do that. (Maybe I'm just misunderstanding how it works, I've never used it before.) No idea. Or complain to Ubuntu that they still have not updated their TeXlive. Done. :-) Maybe downgrading Metapost is an option if you can't figure out how to upgrade. If Ubuntu don't do anything I'll try installing sid packages as you suggested. Can you confirm that my list of missing build dependencies is accurate? I'd be happy to send a CG patch about this (assuming I get to the point of a working build:-) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond build dependencies
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 05/10/13 19:01, David Kastrup wrote: Maybe you can use tlmgr for updating your Metapost. Well, you saw the error I encountered when trying to use tlmgr to do that. (Maybe I'm just misunderstanding how it works, I've never used it before.) No idea. Or complain to Ubuntu that they still have not updated their TeXlive. Done. :-) Maybe downgrading Metapost is an option if you can't figure out how to upgrade. If Ubuntu don't do anything I'll try installing sid packages as you suggested. Can you confirm that my list of missing build dependencies is accurate? They look plausible, but I have no idea whether they would be complete. I'd be happy to send a CG patch about this (assuming I get to the point of a working build:-) -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Does the LilyPond build generate shared libraries you can use with Guile (load-extension) ?
Hi all,
Is there am easy way of generating a shared library with all the
scheme definitions generated in code by the C++ macro LY_DEFINE and
friends? I would like have a way of testing scheme files from the
Guile repl.
It would take some of the grief out of hacking for the Guile V2 scheme
port as I can debug and test scheme files from the shell and the REPL
without having to hack lily.scm all the time.
Cheers,
Ian Hulin
(This is from the Guile documentation, what I'm after is the
equivalent of the libguile-bessel.so )
===
A library that is linked into Guile is called an extension, but it
really just is an ordinary object library.
The following example shows how to write a simple extension for Guile
that makes the j0 function available to Scheme code.
#include math.h
#include libguile.h
SCM
j0_wrapper (SCM x)
{
return scm_make_real (j0 (scm_num2dbl (x, j0)));
}
void
init_bessel ()
{
scm_c_define_gsubr (j0, 1, 0, 0, j0_wrapper);
}
This C source file needs to be compiled into a shared library. Here is
how to do it on GNU/Linux:
gcc `pkg-config --cflags guile-2.0` \
-shared -o libguile-bessel.so -fPIC bessel.c
For creating shared libraries portably, we recommend the use of GNU
Libtool (see Introduction).
A shared library can be loaded into a running Guile process with the
function load-extension. The j0 is then immediately available:
$ guile
scheme@(guile-user)
(load-extension ./libguile-bessel init_bessel)
scheme@(guile-user) (j0 2)
$1 = 0.223890779141236
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Generating compiled scm (.go) files as part of LilyPond build
Greets,
On Tue 19 Jul 2011 15:28:41 BST, Andy Wingo wrote:
On Tue 19 Jul 2011 15:18, Ian Hulin i...@hulin.org.uk writes:
It may boil down to a matter of taste, but I find double and
triple extensions on a filename intrinsically nasty. I've normally
come across them before on Windows systems where a filename such as
thing.htm.exe usually means there's malware or a trojan or suchlike
on your system. See also comments below.
Consider it an opaque key into a cache. We could change in the
future to default to the SHA1 of the whole path. That does have
some advantages regarding flattening the directory hierarchy,
resulting in fewer stat operations.
Sorry, but how does this benefit LilyPond as a user of the Guile API?
I'm used to viewing file extensions as an indication of the format of
the file content. In our simple view scheme sources are *.scm, and
compiled scheme files are *.go.
Not sure I understand here; LilyPond would benefit from such a scheme
due to having various operations be faster, and by continuing to not
have to worry about the form of these file names.
Guile documentation implies something similar (Chap 4 Environment
Variable sections on GUILE_AUTO_COMPILE and GUILE_LOAD_COMPILED_PATH)
If a compiled (‘.go’) file corresponding to a ‘.scm’ file is not found
or is not newer than the ‘.scm’ file, the ‘.scm’ file will be compiled
on the fly, and the
resulting ‘.go’ file stored away. An advisory note will be printed on
the console.
GUILE_LOAD_COMPILED_PATH
This variable may be used to augment the path that is searched for
compiled Scheme files (‘.go’ files) when loading
Neither of these sections leads the reader to expect an actual file name
generated to be
;;; compiled
/long/path/name/testing.scm.go
^^^
I think that we need to be clear here, that Guile really cannot commit
to the form of the names of auto-compiled files. That is not part of
Guile's API.
The reason for a simple string-append is that it is very possible to
compile a file named /long/path/name/testing *and also* a file named
/long/path/name/testing.scm. Appending a suffix is a simple and
effective means to ensuring a unique cache key.
ian@nanny-ogg:~/src/Guile/guile-2.0.2$ meta/guile -L $PWD
This will set XDG_CACHE_HOME=${top_builddir}/cache.
The Guile Reference Manual Chapter 4 p 38 specifically says this
defaults to $HOME/cache
Not when running uninstalled, with meta/guile. Many things are
different in that case.
The problem is knowing where the cache is. For Lilypond, we need to
have a common root directory off of which we can hang the compiled
files in scm/out.
Why do you care? (Honest question.)
(Honest answer)
Because if Lilypond is run up with the Guile default of --auto-compile
it will check for and generate compiled files in a different place to
where we want to have produced them at build-time. Also once for a
project like LilyPond these files would need to be in a shared directory
on the file system. Relying on the default compiled file spec would have
a set of cached files somewhere on each user's cache in their home
directory.
I don't understand why this isn't working for you. I think we need to
be very specific. Let's look at am/guilec from Guile itself. It has:
# -*- makefile -*-
GOBJECTS = $(SOURCES:%.scm=%.go)
GUILE_WARNINGS = -Wunbound-variable -Warity-mismatch -Wformat
moddir = $(pkgdatadir)/$(GUILE_EFFECTIVE_VERSION)/$(modpath)
nobase_mod_DATA = $(SOURCES) $(NOCOMP_SOURCES)
ccachedir = $(pkglibdir)/$(GUILE_EFFECTIVE_VERSION)/ccache/$(modpath)
nobase_ccache_DATA = $(GOBJECTS)
EXTRA_DIST = $(SOURCES) $(NOCOMP_SOURCES)
ETAGS_ARGS = $(SOURCES) $(NOCOMP_SOURCES)
CLEANFILES = $(GOBJECTS)
# Make sure source files are installed first, so that the mtime of
# installed compiled files is greater than that of installed source
# files. See
# http://lists.gnu.org/archive/html/guile-devel/2010-07/msg00125.html
# for details.
guile_install_go_files = install-nobase_ccacheDATA
$(guile_install_go_files): install-nobase_modDATA
AM_V_GUILEC = $(AM_V_GUILEC_$(V))
AM_V_GUILEC_ = $(AM_V_GUILEC_$(AM_DEFAULT_VERBOSITY))
AM_V_GUILEC_0 = @echo GUILEC $@;
SUFFIXES = .scm .go
.scm.go:
$(AM_V_GUILEC)GUILE_AUTO_COMPILE=0 \
$(top_builddir)/meta/uninstalled-env\
guild compile $(GUILE_WARNINGS) -o $@ $
Then module/Makefile.am just has to:
include $(top_srcdir)/am/guilec
# We're at the root of the module hierarchy.
modpath =
SOURCES = \
ice-9/psyntax-pp.scm\
ice-9/boot-9.scm\
...
That will result in .go files getting compiled for all Scheme files.
They are compiled in an uninstalled env, which adds the srcdir to the
GUILE_LOAD_PATH, and the builddir to the
Re: Generating compiled scm (.go) files as part of LilyPond build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/01/11 11:21, Andy Wingo wrote: Hi Ian, [re-adding the list; please keep the list CC'd on all guile-related topics] On Fri 28 Jan 2011 22:37, Ian Hulin i...@hulin.org.uk writes: Are you going to fix the double extension bug for defaulted/cached output names? I.e. compiling c++.scm will produce an output filename of c++.scm.go in the cache. As far as I'm concerned this isn't a bug. It only happens for writes to the fallback path. Appending an extension instead of replacing an extension makes the algorithm more robust (e.g, doesn't confuse `foo' and `foo.scm'. It may boil down to a matter of taste, but I find double and triple extensions on a filename intrinsically nasty. I've normally come across them before on Windows systems where a filename such as thing.htm.exe usually means there's malware or a trojan or suchlike on your system. See also comments below. Basically compiled-file-name doesn't do any path searches. It simply computes a place in ~/.cache in which to cache the result of compiling FILE. Yuk! This means we will need to have custom routines in our code to work out and specify the output path we want. There is not a DWIM answer, for various reasons -- but the combinatorics between %load-path, %load-compiled-path, %load-extensions, %load-compiled-extensions, and the actual `load' procedure should give you an idea. The autocompilation strategy is as good as we can get without you actually telling Guile where you want your files. It also means that autocompilation is a hindrance rather than a help, since it hi-jacks the compiled files into the cache. What is the problem with writing to the cache? It is a cache. It's doing it's job. The problem is knowing where the cache is. For Lilypond, we need to have a common root directory off of which we can hang the compiled files in scm/out. I've been able to find out from Guile V2.02 that the cache root can be controlled by an environment variable XDG_CACHE_HOME, which is defaulted by Guile to $HOME/.cache if not defined. The documentation also says that compiled files for will be placed in $XDG_CACHE_HOME/guile/ccache but this is what it actually does: ian@nanny-ogg:~/src/Guile/guile-2.0.2$ meta/guile -L $PWD GNU Guile 2.0.2 Copyright (C) 1995-2011 Free Software Foundation, Inc. Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'. This program is free software, and you are welcome to redistribute it under certain conditions; type `,show c' for details. scheme@(guile-user) (load testing.scm) ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0 ;;; or pass the --no-auto-compile argument to disable. ;;; compiling /home/ian/src/Guile/guile-2.0.2/testing.scm ;;; compiled /home/ian/src/Guile/guile-2.0.2/cache/guile/ccache/2.0-LE-4-2.0/home/ian/src/Guile/guile-2.0.2/testing.scm.go scheme@(guile-user) The output filename looks like it's derived like this The first section of the path /home/ian/src/Guile/guile-2.0.2/cache is controlled by XDG_CACHE_HOME or defaulted, but instead of $HOME/.cache it defaults to $PWD/cache here. The first two sections of the path /home/ian/src/Guile/guile-2.0.2/cache/guile/ccache/2.0-LE-4-2.0 is controlled by %compile-fallback-path using the value derived or defaulted from $XDG_CACHE_HOME for the first section. The third section of the path /home/ian/src/Guile/guile-2.0.2/ is the absolute path of the incoming filename concatenated onto the first two sections. This is unhelpful for what we want to do in Lilypond. If the first two sections are of the path point to a cache base directory, at this point section three of the path should be derived from the *relative* path in the incoming filename. testing.scm.go Lose the .scm bit, it also is unhelpful. If the compiled-file-name used the incoming relative path for the third section we could do the following in our initialization code before calling guile ($LILY_DATADIR is the the root LilyPond directory). 1. Insert $LILY_DATADIR/scm at the head of %load-path and $LILY_DATADIR/scm/out at the head of %load-compiled-path 2. setenv $XDG_CACHE_HOME to $LILY_DATADIR 3. set %compile-fallback-path to $LILY_DATADIR If the double extension feature was also removed, Then the equivalent of (load testing.scm) with auto-compilation on would generate $LILY_DATADIR/scm/testing.go It wouldn't give us _quite_ what we want as the compiled files would be in the same directory as the source files, but we could live with that if it allows us either to use auto-compile, or to rely in Guile's in-built check of the the source and compiled file's modified times. Load (system base compile) then, no? OK, this is another V1.8/V2.0 conditional kludge we need to put in the LilyPond initialization code. Compiling files is a 2.0 thing, of course... It looks like (compiled-file-name) uses a hard-coded default setting for %load-compiled-files to use as
Re: Generating compiled scm (.go) files as part of LilyPond build
Hi Ian,
On Tue 19 Jul 2011 15:18, Ian Hulin i...@hulin.org.uk writes:
It may boil down to a matter of taste, but I find double and triple
extensions on a filename intrinsically nasty. I've normally come across
them before on Windows systems where a filename such as thing.htm.exe
usually means there's malware or a trojan or suchlike on your system.
See also comments below.
Consider it an opaque key into a cache. We could change in the future
to default to the SHA1 of the whole path. That does have some
advantages regarding flattening the directory hierarchy, resulting in
fewer stat operations.
ian@nanny-ogg:~/src/Guile/guile-2.0.2$ meta/guile -L $PWD
This will set XDG_CACHE_HOME=${top_builddir}/cache.
The problem is knowing where the cache is. For Lilypond, we need to have
a common root directory off of which we can hang the compiled files in
scm/out.
Why do you care? (Honest question.)
To me there are two cases:
1) You compile the files yourself. You either ensure that the .go
files end up in the right places, or adjust
GUILE_LOAD_COMPILED_PATH.
2) You rely on autocompilation. In this case there is no guarantee
about where the files go, besides residing in the
XDG_CACHE_DIR/guile.
Regards,
Andy
--
http://wingolog.org/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Generating compiled scm (.go) files as part of LilyPond build
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue 19 Jul 2011 15:28:41 BST, Andy Wingo wrote:
Hi Ian,
On Tue 19 Jul 2011 15:18, Ian Hulin i...@hulin.org.uk writes:
It may boil down to a matter of taste, but I find double and
triple extensions on a filename intrinsically nasty. I've normally
come across them before on Windows systems where a filename such as
thing.htm.exe usually means there's malware or a trojan or suchlike
on your system. See also comments below.
Consider it an opaque key into a cache. We could change in the
future to default to the SHA1 of the whole path. That does have
some advantages regarding flattening the directory hierarchy,
resulting in fewer stat operations.
Sorry, but how does this benefit LilyPond as a user of the Guile API?
I'm used to viewing file extensions as an indication of the format of
the file content. In our simple view scheme sources are *.scm, and
compiled scheme files are *.go.
Guile documentation implies something similar (Chap 4 Environment
Variable sections on GUILE_AUTO_COMPILE and GUILE_LOAD_COMPILED_PATH)
If a compiled (‘.go’) file corresponding to a ‘.scm’ file is not found
or is not newer than the ‘.scm’ file, the ‘.scm’ file will be compiled
on the fly, and the
resulting ‘.go’ file stored away. An advisory note will be printed on
the console.
GUILE_LOAD_COMPILED_PATH
This variable may be used to augment the path that is searched for
compiled Scheme files (‘.go’ files) when loading
Neither of these sections leads the reader to expect an actual file name
generated to be
;;; compiled
/long/path/name/testing.scm.go
^^^
ian@nanny-ogg:~/src/Guile/guile-2.0.2$ meta/guile -L $PWD
This will set XDG_CACHE_HOME=${top_builddir}/cache.
The Guile Reference Manual Chapter 4 p 38 specifically says this
defaults to $HOME/cache
The problem is knowing where the cache is. For Lilypond, we need to
have a common root directory off of which we can hang the compiled
files in scm/out.
Why do you care? (Honest question.)
(Honest answer)
Because if Lilypond is run up with the Guile default of --auto-compile
it will check for and generate compiled files in a different place to
where we want to have produced them at build-time. Also once for a
project like LilyPond these files would need to be in a shared directory
on the file system. Relying on the default compiled file spec would have
a set of cached files somewhere on each user's cache in their home
directory.
To me there are two cases:
1) You compile the files yourself. You either ensure that the .go
files end up in the right places, or adjust
GUILE_LOAD_COMPILED_PATH.
But GUILE_LOAD_COMPILED_PATH setting won't prevent the vanilla
compiled-file-name from checking in the wrong place for at compile time.
OK we can brew our own expectation of where the file will be, and
provide our own ly:load and intelligence to pick up the compiled file,
but we have to do this in conjunction with a
scm_putenv(GUILE_AUTO_COMPILE=0) call in our initialization code.
2) You rely on autocompilation. In this case there is no guarantee
about where the files go, besides residing in the
XDG_CACHE_DIR/guile.
Looks like this is a no-no. We can't control what the files are called,
or if they'd be recognized once they've been moved to their location
after /make install/ for LilyPond. Also there's the issue of embedded
Scheme statements in Lily source files (which could contain their own
(load ) statements).
It's a real shame because it looks like auto-compile is a feature
designed to make life easy for Guile users (including layered projects
like LilyPond). Unfortunately its default settings prevent us from using
it. :-(.
I've also got a question re the (include) procedure which Ludovic
mentioned in a post on guile-users. I'll start a different thread for
that one.
Thanks for the help so far,
Cheers,
Ian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJOJg5cAAoJEBqidDirZqASMj0H/2jn/jiNG+MtT+YEc762baxL
8pMC4ijNMwWEnMwzuWm1LHhHiJqG5roxvinPoe5bjeC8RBNSMOW7SKGkJ+ao5pTK
vYfBm55WqdpAvAVQA9OaDkL6J33TEa6z1ioNYxj2yFOHHsj0HHVnhUM29RDNYgmw
9duK9lKtv37AGT0W9aj6bGx8FRGFUOFgRUnHMCtn7usE1DboXQgjaY3IQ46XYs6n
XGfuFz1JBXqhKEjjK7Fbu5M44A0eD2yWGJ01K3eVQqB1OmIrz7zy7wU495Wqd4im
/eop+BCJRnpRAdHIR0y/LgrrlPSpD+mulBk9BOuoAglXM6N8spaQQY/mj8MkrKU=
=igTg
-END PGP SIGNATURE-
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Jan Nieuwenhuizen wrote: Well, it's a dangerous thing. Among other things, their version numbers might collide badly with the official Debian ones. Best it should have different package names to prevent this sort of thing from happening. Whe have this on our website, I think that Anthoy Fok provided this recipe We could also just copy your ./debian stuff and change the name to lilypond-snapshot and lilypond-2.6-snapshot or something? then again, who actually uses these recipes? We have spec files for Fedora, Mandrake and SUSE, and only the Fedora one gets regular maintenance, because I use it to build the RPM myself. Perhaps it's better to put them into a separate packaging CVS repo. -- 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: a new lilypond build failure
Jan Nieuwenhuizen [EMAIL PROTECTED] writes: Well, it's a dangerous thing. Among other things, their version numbers might collide badly with the official Debian ones. Best it should have different package names to prevent this sort of thing from happening. Whe have this on our website, I think that Anthoy Fok provided this recipe The build scripts are in the subdirectory codedebian//code; you can make the .deb by doing tar xzf lilypond-x.y.z.tar.gz cd lilypond-x.y.z dpkg-checkbuilddeps # print missing build dependencies # apt-get install ... # install any missing packages dch -p -v x.y.z.local.1 Local build. debuild We could also just copy your ./debian stuff and change the name to lilypond-snapshot and lilypond-2.6-snapshot or something? Yes, that is a safer recipe. If you copy my ./debian code, that's ok, but still, I'd rather it didn't land inside the standard tarball but lived separately. Also, there will be necessary version skew: I make my change only after you release the tarball. Since the virtue of this is for users who are using the CVS archive (and I do see the point of that) how about leaving it in the CVS, but not packaging it into the tarball? That seems like the best of both worlds. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Jan Nieuwenhuizen [EMAIL PROTECTED] writes: Ok; they were once used for processing the texinfo docs, right? They are still used for producing the PDF documentatation, so there is still a build dependency on tetex. Also, tetex is great for making documents with lilypond snippets, but this does not make tetex a dependency (now that we dropped it). Ah, yes, we get that from mftrace anyway, since mftrace depends on tetex-bin in Debian. :) You say that the TeX backend is no longer supported (!). Why is this? TeX used to be our easy way out to produce output. In the 2.5 series, we managed to use pango to make the half-baken PS backend fully operational. Supporting tex output is a lot of work, and it probably has just one user. I used to use it a lot. Ah well. :) Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Han-Wen Nienhuys writes: Perhaps it's better to put them into a separate packaging CVS repo. Yes, let's just [re]move them all. The mingw/cygwin stuff is already in the installer repo. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Han-Wen Nienhuys writes: then again, who actually uses these recipes? Now I remember, we used to have debian repackagers of development releases for debian stable and debian unstable. Anyway, what I'd really like to do is to build debs of any software that I need which is not in Debian (mostly new releases or CVS), and install in a writable ~/.unionfs overlay of /. For that to work, we not only need an efficient unionfs that works with fuse (or a unionfs translator for the Hurd), but also an up to date ./debian directory in every software package that I need. I was thinking of doing our part with LilyPond, but the idea is not really taking off. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Thomas Bushnell writes:
But now there's a new, more subtle, one.
Fixed in CVS, see patch below.
Thanks for the report (and sorry that this kludge survived in the first place).
Jan.
Index: ChangeLog
===
RCS file: /cvsroot/lilypond/lilypond/ChangeLog,v
retrieving revision 1.3836.2.42
diff -p -u -r1.3836.2.42 ChangeLog
--- ChangeLog 23 Oct 2005 15:58:39 - 1.3836.2.42
+++ ChangeLog 23 Oct 2005 19:03:38 -
@@ -1,3 +1,8 @@
+2005-10-23 Jan Nieuwenhuizen [EMAIL PROTECTED]
+
+ * scm/lily.scm: Remove horrendous running-from-gui? kludge.
+ (lilypond-main): Redirect to gui-main if 'gui is set.
+
2005-10-23 Erik Sandberg [EMAIL PROTECTED]
* scripts/lilypond-book.py: Backport bugfix by Mats Bengtsson.
Index: lily/lily-parser-scheme.cc
===
RCS file: /cvsroot/lilypond/lilypond/lily/lily-parser-scheme.cc,v
retrieving revision 1.16
diff -p -u -r1.16 lily-parser-scheme.cc
--- lily/lily-parser-scheme.cc 22 Jun 2005 15:06:05 - 1.16
+++ lily/lily-parser-scheme.cc 23 Oct 2005 19:02:10 -
@@ -8,15 +8,16 @@
#include unistd.h
+#include file-name-map.hh
#include file-name.hh
#include file-path.hh
-#include main.hh
-#include lily-parser.hh
-#include warn.hh
-#include source.hh
#include lily-lexer.hh
+#include lily-parser.hh
#include ly-module.hh
-#include file-name-map.hh
+#include main.hh
+#include program-option.hh
+#include source.hh
+#include warn.hh
/* Do not append `!' suffix, since 1st argument is not modified. */
LY_DEFINE (ly_set_point_and_click, ly:set-point-and-click,
@@ -52,7 +53,7 @@ LY_DEFINE (ly_parse_file, ly:parse-file
/* When running from gui, generate output in .ly source directory. */
if (output_name_global.is_empty ()
- scm_call_0 (ly_lily_module_constant (running-from-gui?)) == SCM_BOOL_T)
+ ly_get_option (ly_symbol2scm (gui)) == SCM_BOOL_T)
{
File_name f (file);
f.base_ = ;
Index: scm/lily.scm
===
RCS file: /cvsroot/lilypond/lilypond/scm/lily.scm,v
retrieving revision 1.367.2.3
diff -p -u -r1.367.2.3 lily.scm
--- scm/lily.scm 1 Aug 2005 15:14:46 - 1.367.2.3
+++ scm/lily.scm 23 Oct 2005 19:02:10 -
@@ -348,6 +348,9 @@ The syntax is the same as `define*-publi
(define-public (lilypond-main files)
Entry point for LilyPond.
+ (if (ly:get-option 'gui)
+ (gui-main files))
+
(if (null? files)
(no-files-handler))
@@ -385,29 +388,12 @@ The syntax is the same as `define*-publi
(use-modules (scm editor))
-(define-public (running-from-gui?)
- (let ((have-tty? (isatty? (current-input-port
-;; If no TTY and not using safe, assume running from GUI.
-(cond
- ((eq? PLATFORM 'windows)
- ;; Always write to .log file.
- (if DOS #t
- ;; This only works for i586-mingw32msvc-gcc -mwindows
- (not (string-match standard input
- (format #f ~S (current-input-port))
- ;; FIXME: using -dgui would be nice, but it does not work
- ((eq? PLATFORM 'foo-windows)
- (ly:get-option 'gui))
- ((eq? PLATFORM 'darwin) #f)
- (else
- (not have-tty?)
-
(define-public (gui-main files)
(if (null? files)
(gui-no-files-handler))
(let* ((base (basename (car files) .ly))
(log-name (string-append base .log)))
-(if (not (running-from-gui?))
+(if (not (ly:get-option 'gui))
(ly:message (_ Redirecting output to ~a...) log-name))
(ly:stderr-redirect log-name w)
(ly:message # -*-compilation-*-)
@@ -430,7 +416,3 @@ The syntax is the same as `define*-publi
(ly:message (_ Invoking `~a'...) cmd)
(system cmd)
(exit 1)))
-
-(or (not (running-from-gui?))
-(ly:get-option 'safe)
-(define lilypond-main gui-main))
--
Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Thomas Bushnell writes: Anyway, with my patch (or equivalently with yours, I'm sure), lilypond 2.6.3 is now in Debian. (Whew!) That's great, thanks a lot for your efforts. I'm going to start going through the many Debian bug reports That's a good thing too. Btw, have you checked the dependencies? LilyPond no longer uses ec-fonts-mftraced I think the package musixtex-fonts does not exist and if it does, I cannot imagine any conflicts. Also, as LilyPond does not use tex by default libkpathsea3 tetex-bin tetex-extra are not requirement anymore. They may be useful, and are required when using the (unsupported) TeX backend. Lilypond is such a great thing, I'm glad that finally Debian users will have an up-to-date package at least in Debian unstable. Thanks! Yes, that's great. And don't forget the Ubuntu users. Oh, and a request: the debian/ directory in the tarballs that you all distribute isn't very helpful to me I always liked to distribute this for users to build their own deb package [from CVS]. What do you think? Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: a new lilypond build failure
Han-Wen Nienhuys [EMAIL PROTECTED] writes:
Thomas Bushnell BSG wrote:
ec-fonts-mftraced
Wait, you mean showed up and is now gone? What's it for anymore?
Why
did we ever have it? :)
It was for Lily 2.4, which supported Latin1 encoding and fonts, but not
unicode.
I see, so now that Unicode is supported, it's not relevant.
Does that mean that nobody will ever want ec-fonts-mftraced anymore?
(If so, I can drop the Debian package itself too.)
No, Lily used to be linked against libkpathsea to locate TeX fonts, so
it could determine dimensions of texts. This is no longer necessary with
Pango. LilyPond now outputs PS directly, which you can include into TeX
with \includegraphics{}. Supporting TeX (with all of its crappy support
tools) was one of the major headaches of deploying LilyPond, and I'm
very glad it's gone.
If the manual suggests .tex is the default, then that would be a bug in
the manual then; can you pinpoint it more exactly?
Let me check to make sure I have the right version of the manual. :)
I'll get back to you on that.
Thomas
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
a new lilypond build failure
So delightfully, mftrace version 1.1.17 does indeed fix the previous build problems. But now there's a new, more subtle, one. Normal Debian automatic build procedure is to build things with input redirected from /dev/null. This causes a failure in running lilypond for documentation generation. The command invoked is from lilypond-2.6.3/Documentation/user, and is /home/debian/lilypond-2.6.3/lily/out/lilypond --verbose /home/debian/lilypond-2.6.3/ly/generate-documentation If the input is a terminal, this works fine, and prints the following output: GNU LilyPond 2.6.3 LILYPOND_DATADIR=/usr/share/lilypond/2.6.3 LOCALEDIR=/usr/share/locale Effective prefix: /usr/share/lilypond/2.6.3 Initializing FontConfig... adding font directory: /usr/share/lilypond/2.6.3/fonts/otf/ adding font directory: /usr/share/lilypond/2.6.3/fonts/type1/ adding font directory: /usr/share/lilypond/2.6.3/fonts/svg/ Processing `/home/debian/lilypond-2.6.3/ly/generate-documentation.ly' Parsing...[/usr/share/lilypond/2.6.3/ly/init.ly[/usr/share/lilypond/2.6.3/ly/declarations-init.ly[/usr/share/lilypond/2.6.3/ly/music-functions-init.ly][/usr/share/lilypond/2.6.3/ly/nederlands.ly][/usr/share/lilypond/2.6.3/ly/drumpitch-init.ly][/usr/share/lilypond/2.6.3/ly/chord-modifiers-init.ly][/usr/share/lilypond/2.6.3/ly/script-init.ly][/usr/share/lilypond/2.6.3/ly/scale-definitions-init.ly][/usr/share/lilypond/2.6.3/ly/grace-init.ly][/usr/share/lilypond/2.6.3/ly/midi-init.ly[/usr/share/lilypond/2.6.3/ly/performer-init.ly]][/usr/share/lilypond/2.6.3/ly/paper-defaults.ly[/usr/share/lilypond/2.6.3/ly/titling-init.ly]][/usr/share/lilypond/2.6.3/ly/engraver-init.ly][/usr/share/lilypond/2.6.3/ly/dynamic-scripts-init.ly][/usr/share/lilypond/2.6.3/ly/spanners-init.ly][/usr/share/lilypond/2.6.3/ly/property-init.ly]][/home/debian/lilypond-2.6.3/ly/generate-documentation.ly[/usr/share/lilypond/2.6.3/scm/documentation-lib.scm][/usr/share/lilypond/2.6.3/scm/document-functions.scm][/usr/share/lilypond/2.6.3/scm/document-translation.scm][/usr/share/lilypond/2.6.3/scm/document-music.scm][/usr/share/lilypond/2.6.3/scm/document-backend.scm][/usr/share/lilypond/2.6.3/scm/document-markup.scm] Writing lilypond-internals.texi... ]] But if the input is redirected from /dev/null, it exits after printing: LILYPOND_DATADIR=/usr/share/lilypond/2.6.3 LOCALEDIR=/usr/share/locale Effective prefix: /usr/share/lilypond/2.6.3 Initializing FontConfig... adding font directory: /usr/share/lilypond/2.6.3/fonts/otf/ adding font directory: /usr/share/lilypond/2.6.3/fonts/type1/ adding font directory: /usr/share/lilypond/2.6.3/fonts/svg/ And it does not generate any of the proper output files that should be generated. Moreover, the trailing newline after /svg/ is not printed. This premature exit reports exit status zero (which also caused considerable pain in locating this as the source of the problems I'm having!). This happens with a lilypond that otherwise seems to work fine. Thomas ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond build
Hello all,
I have just cvs updated lily. since I upgraded my system
(FreeBSD 5.0 lily don't build due to gcc (please see below).
A patch or something like lexer-gcc-3.2.1.sh will be ineeded and appreciated?
Many thanks.
raoul
[EMAIL PROTECTED]
===cut
In file included from include/includable-lexer.hh:14,
from includable-lexer.cc:13:
out/FlexLexer.h:64: `istream' was not declared in this scope
out/FlexLexer.h:64: `s' was not declared in this scope
out/FlexLexer.h:64: syntax error before `)' token
out/FlexLexer.h:64: virtual outside class declaration
out/FlexLexer.h:64: initializer list being treated as compound expression
out/FlexLexer.h:66: `istream' was not declared in this scope
out/FlexLexer.h:66: `s' was not declared in this scope
out/FlexLexer.h:66: virtual outside class declaration
out/FlexLexer.h:66: variable or field `yyrestart' declared void
out/FlexLexer.h:71: `istream' was not declared in this scope
out/FlexLexer.h:71: `new_in' was not declared in this scope
out/FlexLexer.h:71: `ostream' was not declared in this scope
out/FlexLexer.h:71: `new_out' was not declared in this scope
out/FlexLexer.h:72: initializer list being treated as compound expression
out/FlexLexer.h:72: syntax error before `{' token
out/FlexLexer.h: In member function `const char* FlexLexer::YYText()':
out/FlexLexer.h:58: `yytext' undeclared (first use this function)
out/FlexLexer.h:58: (Each undeclared identifier is reported only once for each
function it appears in.)
out/FlexLexer.h: In member function `int FlexLexer::YYLeng()':
out/FlexLexer.h:59: `yyleng' undeclared (first use this function)
out/FlexLexer.h: At global scope:
out/FlexLexer.h:79: warning: `virtual' is not at beginning of declaration
out/FlexLexer.h:79: `istream' was not declared in this scope
out/FlexLexer.h:79: `new_in' was not declared in this scope
out/FlexLexer.h:80: `ostream' was not declared in this scope
out/FlexLexer.h:80: `new_out' was not declared in this scope
out/FlexLexer.h:80: two or more data types in declaration of `switch_streams'
out/FlexLexer.h:80: virtual outside class declaration
out/FlexLexer.h:80: cannot declare variable `switch_streams' to be of type `
FlexLexer'
out/FlexLexer.h:80: because the following virtual functions are abstract:
out/FlexLexer.h:68: virtual int FlexLexer::yylex()
out/FlexLexer.h:65: virtual void FlexLexer::yy_delete_buffer(yy_buffer_state*)
out/FlexLexer.h:62: virtual void
FlexLexer::yy_switch_to_buffer(yy_buffer_state*)
out/FlexLexer.h:80: assignment (not initialization) in declaration
out/FlexLexer.h:82: non-member function `int lineno()' cannot have `const'
method qualifier
out/FlexLexer.h: In function `int lineno()':
out/FlexLexer.h:82: `yylineno' undeclared (first use this function)
out/FlexLexer.h: At global scope:
out/FlexLexer.h:84: non-member function `int debug()' cannot have `const'
method qualifier
out/FlexLexer.h: In function `int debug()':
out/FlexLexer.h:84: `yy_flex_debug' undeclared (first use this function)
out/FlexLexer.h: At global scope:
out/FlexLexer.h:87: syntax error before `protected'
out/FlexLexer.h:89: `int yyleng' used prior to declaration
out/FlexLexer.h:90: `int yylineno' used prior to declaration
out/FlexLexer.h:91: `int yy_flex_debug' used prior to declaration
out/FlexLexer.h:94: syntax error before `}' token
In file included from include/includable-lexer.hh:14,
from includable-lexer.cc:13:
out/FlexLexer.h:44:1: unterminated #ifndef
In file included from includable-lexer.cc:13:
include/includable-lexer.hh:10:1: unterminated #ifndef
=
# gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.2.2 [FreeBSD] 20030205 (release)
==
___
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: guile-1.4 shared patch (was: Re: lilypond build on cygwin stucks)
Jan Nieuwenhuizen schrieb am 2001-09-20, 9:54: Gerrit P. Haase [EMAIL PROTECTED] writes: Jan Nieuwenhuizen schrieb am 2001-09-18, 22:04: Well now, after several attempts, I got it managed to build guile on Cygwin with shared libs (libguile.dll libguilereadline.dll). Now it is: guile-1.4-2. The patch is up (because 30K), i hope it works for others, too. http://familiehaase.de/cywgin/guile/guile-1.4-2.patch I have updated the patch today, because it seems the import library gets not built (and not installed ), but there is one generated when linking libguilereadline with libguile.dll so we can take this. Needs to be copied and renamed manually. I have not tried yet to link against this import lib with a libtoolized package, is there one somewhere which I can use to test the libguil.la and import-lib? ( Patch is at same location, same name). LilyPond links o.k with that importlib, i built it yesterday, needs some testing yet. Ok, that looks good. Where did you get the autogen.sh and autobuild.sh scripts; I mean, why do they need to be in the patch? I wrote it, parts are from the autogen.sh of current guile (1.7) and other parts are from me. autobuild.sh is just a bundle of all steps i did to get it up and running so i was able to link against libguile.dll. If you type sh -x ./autobuild.sh all should be managed by this script. If you type 'sh -x autogen.sh' only the configure and Makefile.in scripts were updated plus a new version of libtool is copied in the lt subdir. Also, you add AC_LIBTOOL_WIN32_DLL to configure.in, that looks rather cygwin specific... That is for libtool to tell it to build win32 .dll's:) For cross-compiling guile, we'll still need the arch-guile-config patch on top of this. O.k. I don't know about problems with crosscompiling. But it should be possible to build .dll's at a linux box, though I don't know. You are talking about this: #!/bin/sh # target-guile-config.in case $1 in --version) echo 1.4 exit 0 ;; compile) echo -I/home/cygwin/cygwin-1.3.2/usr/include -I/home/cygwin/cygwin-1.3.2/usr/include/w32api exit 0 ;; link) echo -lguile -L/home/cygwin/cygwin-1.3.2/usr/lib -lregex /home/cygwin/cygwin-1.3.2/usr/bin/cygwin1.dll exit 0 ;; esac Question: = I don't need to include win32api for a 'native' cygwin build. Do you compile with -mno-cygwin flag? And you are linking against cygwin1.dll? Standard is to put the import libs on the link line (libcygwin.a). If I link against libcygwin.a I don't need w32api and vice versa. This arch-guile-config is of no use after it is installed on cygwin. Gerrit -- =^..^= ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
guile-1.4 shared patch (was: Re: lilypond build on cygwin stucks)
Jan Nieuwenhuizen schrieb am 2001-09-18, 22:04: Well now, after several attempts, I got it managed to build guile on Cygwin with shared libs (libguile.dll libguilereadline.dll). Now it is: guile-1.4-2. The patch is up (because 30K), i hope it works for others, too. http://familiehaase.de/cywgin/guile/guile-1.4-2.patch How to build it: Requires *all* of Cygwin *plus* libtool-1.4.2 I included two scripts in the patch. Besides that, there are some minor changes in configure.in and Makefile.am scripts and some changes to get a clean build on Cygwin. First script: = 'autogen.sh' which is important. This is a *must run* to update all the Makefile.in templates and some other files. And it is a *must run* with autoconf 2.52e and automake 1.5 and libtool 1.4.2 (binary - http://familiehaase.de/cywgin/libtool/). I bet it fails if the autotools are older. Additional instructions are at the Wiki site now: http://lilypond.org/wiki/?GuilePatch Second script: == 'autobuild.sh' There is all included so nothing else needs to be done *after* patching. The script is in the patch, so patching needs to be done at first. Put guile-1.4 source and the patch in some directory, unpack guile, bash$ cd guile-1.4 bash$ patch -p1../guile-1.4-2.patch You may run 'sh ./autobuild.sh' now and after a while..., all should be ready done. Please feel free to ask if there are problems. To get the resource for Pyhton, I've also built latest Python cvs source, but there will be an update of python for Cygwin soon (I hope so). Now the only thing left (for tomorrow) is building LilyPond, which requires also python tetex plus (what I have not figured out yet) hopefully no patches. *all* is at least: cygwin, gawk, less, ncurses, sed, textutils, ash, gcc, autoconf, diff, gdb, m4, automake, make, sh-utils, bash, grep, tar, binutils crypt, fileutils, groff, patch, zlib, bison, ctags, findutils, gzip termcap, flex, inetutils, regex, texinfo, perl, ghostscript, readline *plus* is: libtool-1.4.2 Gerrit -- http://lilypond.org/wiki/?CompilingOnWindows -- =^..^= ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond build on cygwin stucks
Gerrit P. Haase [EMAIL PROTECTED] writes: uh, kpathsea.h includes kpatsea/getopt.h and getopt.h, which doesn't work. Not on cygwin, only kpathsea/getopt.h is included: on cygwin, getopt.h is included through unistd.h. both are unneeded, that's why you cat use the -D__GETOPT_H__ workaround. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond build on cygwin stucks
Jan Nieuwenhuizen schrieb am 2001-09-18, 17:26: Gerrit P. Haase [EMAIL PROTECTED] writes: Jan Nieuwenhuizen schrieb am 2001-09-17, 11:53: Gerrit P. Haase [EMAIL PROTECTED] writes: [..] Ok, that's fine. See my edits to the wiki. ... it is not possible to post the GuilePatch here. (Try again --jcn) That means, if I open the edit window again, the line-breaks and tabs are o.k. then? If they aren't, your web browser or form editor is broken. Well now after building as a shared version, the patch is about 2MB. That's rediculous. The full guile sources are about 5MB. Your patch probably contains lots of generated files. Hmmm, there are the Makefiles included, but not much more. The point is that I did a complete update to current autoconf, automake, libtool. So most of the configuration files are changed. Do you think shared libraries are an improvement, eg, how do you intend to address the versioning issue? I called it: $ guile --version Guile 1.4-gph-1 And the package is named: guile-1.4-gph-1-dll.tar.bz2 Gerrit -- =^..^= ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond build on cygwin stucks
Jan Nieuwenhuizen schrieb am 2001-09-17, 21:06: Gerrit P. Haase [EMAIL PROTECTED] writes: What kind of bug do you think of? uh, kpathsea.h includes kpatsea/getopt.h and getopt.h, which doesn't work. And I saw that unistd.h now includes getopt.h by default, too. That is too bad. I use an old unistd.h where it wasn't included, I have a backup from 2001-05 so I think it is in there since cygwin-1.3.2. Have you offerd a fix to cygwin folks? No, I've only got a workaround yet, not a fix. Also, offering patches to cygwin is a tedious process, and this is a very small thing. Hmmm, in that case it is really complex. I think I'm the first now who got problems with the include of getopt.h in unistd.h. If if also in kpathsea/kpathsea.h, this is trivial and a bug in the tetex-package. Gerrit -- =^..^= ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond build on cygwin stucks
Gerrit P. Haase [EMAIL PROTECTED] writes: I got compiletime errors: = rm -f ./out/kpath.dep; DEPENDENCIES_OUTPUT=./out/kpath.dep ./out/kpath.o g++ -c -DHAVE_ CONFIG_H -DSTRING_UTILS_INLINED -Iinclude -I./out -I.././lib/include -I../lib/./out -I../ ./flower/include -I../flower/./out -I../flower/include -O2 -finline-functions -g -O2 - finline-functions -g -DSTRING_UTILS_INLINED -I/usr/local/include -Wall -W -Wmissing-pro totypes -Wconversion kpath.cc -o out/kpath.o In file included from /usr/include/kpathsea/kpathsea.h:27, from kpath.cc:19: /usr/include/kpathsea/getopt.h:99: redefinition of `struct option' /usr/include/getopt.h:46: previous definition here /usr/include/kpathsea/getopt.h:128: declaration of C function `int getopt_long(int, char * const *, const char *, const option *, int *)' conflicts with /usr/include/getopt.h:56: previous declaration `int getopt_long(int, char **, char *, opti on *, int *)' here That's strange. /usr/include/getopt.h should not get included at all. You should check who's doing that, eg add a #warning to the top getopt.h and recompile, see what happens. lily-guile.cc: In function `class String ly_scm2string(scm_unused_struct *)': lily-guile.cc:187: passing `int *' as argument 2 of `gh_scm2newstr(scm_unused_struct *, size_t *)' changes signedness make[1]: *** [out/lily-guile.o] Error 1 make[1]: Leaving directory `/perl/stuff/sound/lilybuild/lilypond-1.4.7/lily' make: *** [all] Error 2 Are you using a newer guile? LilyPond 1.5.2 has seen fixes for latest (at that time) cvs guile, that won't be backported to lily-1.4. You should use guile 1.3.4 or guile 1.4 with lilypond-1.4. Patches to compile guile for cygwin are in the cygwin-cross package. Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond build on cygwin stucks
Jan Nieuwenhuizen schrieb am 2001-09-16, 11:52: Gerrit P. Haase [EMAIL PROTECTED] writes: I got compiletime errors: = rm -f ./out/kpath.dep; DEPENDENCIES_OUTPUT=./out/kpath.dep ./out/kpath.o g++ -c -DHAVE_ CONFIG_H -DSTRING_UTILS_INLINED -Iinclude -I./out -I.././lib/include -I../lib/./out -I../ ./flower/include -I../flower/./out -I../flower/include -O2 -finline-functions -g -O2 - finline-functions -g -DSTRING_UTILS_INLINED -I/usr/local/include -Wall -W -Wmissing-pro totypes -Wconversion kpath.cc -o out/kpath.o In file included from /usr/include/kpathsea/kpathsea.h:27, from kpath.cc:19: /usr/include/kpathsea/getopt.h:99: redefinition of `struct option' /usr/include/getopt.h:46: previous definition here /usr/include/kpathsea/getopt.h:128: declaration of C function `int getopt_long(int, char * const *, const char *, const option *, int *)' conflicts with /usr/include/getopt.h:56: previous declaration `int getopt_long(int, char **, char *, opti on *, int *)' here That's strange. /usr/include/getopt.h should not get included at all. You should check who's doing that, eg add a #warning to the top getopt.h and recompile, see what happens. lily-guile.cc: In function `class String ly_scm2string(scm_unused_struct *)': lily-guile.cc:187: passing `int *' as argument 2 of `gh_scm2newstr(scm_unused_struct *, size_t *)' changes signedness make[1]: *** [out/lily-guile.o] Error 1 make[1]: Leaving directory `/perl/stuff/sound/lilybuild/lilypond-1.4.7/lily' make: *** [all] Error 2 Are you using a newer guile? LilyPond 1.5.2 has seen fixes for latest (at that time) cvs guile, that won't be backported to lily-1.4. I used guile-1.4 to at buildtime. I'm trying to build guile-1.5.2 with dll's, but it doesn't work yet. You should use guile 1.3.4 or guile 1.4 with lilypond-1.4. Patches to compile guile for cygwin are in the cygwin-cross package. Ah, the patches doesn't fit here. There are only some related to cross-compiling stuff. But the problem with net_db.c and and_let*.scm are not adressed. I will try to send my patch so everyone on cygwin should succeed to compile guile-1.4 without errors. Another problem is that i would like to include libregex automagically so the user simply can do 'configure; make; make install' after patching. Another solution would be to distribute a patched source like usual for cygwin. Gerrit -- =^..^= ___ Lilypond-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/lilypond-devel
