Re: Run regression tests for lilypond-book (issue 2223). (issue 5569045)
https://codereview.appspot.com/5569045/diff/3001/input/regression/lilypond-book/GNUmakefile File input/regression/lilypond-book/GNUmakefile (right): https://codereview.appspot.com/5569045/diff/3001/input/regression/lilypond-book/GNUmakefile#newcode36 input/regression/lilypond-book/GNUmakefile:36: # Prevent parallel lilypond-book instances for this subdir On 2020/02/22 22:54:40, hanwenn wrote: > I know this is a long time ago, but can you remember why this was added? As far as I can remember, lilypond-book was not free of concurrency issues with its use of a cache for snippets. Therefore the simplest to avoid any issue with make -j was to disable concurrent calls to lilypond-book. https://codereview.appspot.com/5569045/
Re: CG: Update of Patchy instructions (issue 112280043 by pkx1...@gmail.com)
Don't think it needs another countdown cycle, so the changes below could
be made before pushing.
Cheers,
Julien
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi
File Documentation/contributor/administration.itexi (right):
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode591
Documentation/contributor/administration.itexi:591: The tracker issue's
lable is then changed automatically to
label
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode606
Documentation/contributor/administration.itexi:606: lable is changed
automatically to @qq{Patch-Needs_work}.
label
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode627
Documentation/contributor/administration.itexi:627: 02 0-23/2 * * *
/home/joe/lilypond-extra/patches/lilypond-patchy-staging.py
joe - patchy
https://codereview.appspot.com/112280043/diff/40001/Documentation/contributor/administration.itexi#newcode694
Documentation/contributor/administration.itexi:694: This occurs when
Patchy detects that the commit ID is has not changed
is has - has
https://codereview.appspot.com/112280043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: Update of Patchy instructions (issue 112280043 by pkx1...@gmail.com)
Thanks for this! Some comments.
Cheers,
Julien
https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi
File Documentation/contributor/administration.itexi (right):
https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi#newcode161
Documentation/contributor/administration.itexi:161: knowledge of of
compiling LilyPond and its documentation along with
of of
https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi#newcode172
Documentation/contributor/administration.itexi:172: requires some human
intervention in order to to visually check for any
to to
https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi#newcode178
Documentation/contributor/administration.itexi:178: compile, including
building all the LilyPond documentation, finally
The script makes sure that the new HEAD compiles, it does not attempt to
compile every individual commit.
https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi#newcode238
Documentation/contributor/administration.itexi:238: Commit access
@emph{is} required to test patches, but a valid login
to test patches - to test and push new commits
https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi#newcode256
Documentation/contributor/administration.itexi:256: of the
@file{patches/} directory to your @var{PATH}.
Would be useful to give the exact command line to clone the repo.
https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi#newcode430
Documentation/contributor/administration.itexi:430: The script can also
be run using a @emph{single} tracker issue number as
You can have multiple arguments, each an issue number.
https://codereview.appspot.com/112280043/diff/20001/Documentation/contributor/administration.itexi#newcode525
Documentation/contributor/administration.itexi:525: @unnumberedsubsubsec
Checking the regression test results
OK, I made it this far.
https://codereview.appspot.com/112280043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3 support
On Tue, Mar 18, 2014 at 3:33 AM, David Kastrup d...@gnu.org wrote: I was of the opinion that GUB already uses Python 2.6? GUB master at https://github.com/gperciva/gub (the current official home) definitely does not use python 2.6. It ships python 2.4.5 If you are using GUB master at https://github.com/janneke/gub then it does use python 2.6, but it lacks the fix for python's hashlib module, which then fails to import at run time. I added that fix and a couple others in the previously mentioned pull request. (BTW moving GUB to a user-agnostic home such as https://github.com/lilypondwould make sense to avoid such confusion. After Jan went mostly inactive, Graham took over as the official home, but he is now himself going into inactivity) Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3 support
On Tue, Mar 18, 2014 at 6:24 AM, David Kastrup d...@gnu.org wrote: Julien Rioux jri...@lyx.org writes: (BTW moving GUB to a user-agnostic home such as https://github.com/lilypond would make sense to avoid such confusion. After Jan went mostly inactive, Graham took over as the official home, but he is now himself going into inactivity) Should we try asking Savannah, either non-GNU or GNU? How much work would it be to meet Savannah's licensing/guideline restrictions regarding binary blobs and stuff? How many of those are LilyPond-specific? If there are technically unavoidable obstacles, the special strategical significance of GUB might still make it possible to negotiate about the hosting with Richard Stallman, currently the ultimate decision maker. I think that cross-platform support is currently troublesome for enough projects that the compile under GNU/Linux, provide everywhere approach of GUB would mean a significant concentration of efforts for other GNU projects as well. If you are keen on it, why not? Not sure if it's worth the trouble, though: Maybe more visibility would bring GUB more workers, and in that vein endorsement by a big player would be a boost. Unfortunately, I'm not sure GUB has a strong significance anymore. With no maintainer, no support team, virtually no devs, it's not attractive for new projects, which then opt for other cross-build solutions instead. The current hosting situation isn't bad that we need to take such important actions with savannah. With github, we already have hosting, a platform for contribution and review comments, and relatively strong visibility, at no effort from us. It seems there is confusion about who owns the official repo, which is easily solved if we move the repo from an individual to an organization. And since it's literally a click or two to do that, I though I would suggest it in passing. Anyway, we're sidestepping. Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3 support
On Mon, Mar 17, 2014 at 9:38 PM, Graham Percival gra...@percival-music.cawrote: On Sun, Mar 16, 2014 at 04:41:46PM -0400, Julien Rioux wrote: I think the following would be a good 1-2 punch approach for the current development cycle: First, upgrade python in GUB and make sure we can build current dev and stable branches of lilypond from it. Then bump the python requirement in the dev branch and start migrating to a codebase that supports python 2.6+ and python 3+ Sounds great! Thanks for working on this. When would be a good timing to do the switch in GUB? Probably don't want to mess with releases from the current stable (2.18.x) branch at this point, so maybe wait until after the last 2.18.x is released, whenever that might be? Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3 support
On Tue, Mar 18, 2014 at 10:39 AM, David Kastrup d...@gnu.org wrote: Julien Rioux jri...@lyx.org writes: The current hosting situation isn't bad that we need to take such important actions with savannah. With github, we already have hosting, a platform for contribution and review comments, and relatively strong visibility, at no effort from us. Who is we? I for one am not going to agree to GitHub's quite invasive usage conditions for their free offerings which include killing a project for any reason they want to at any point of time, explicitly citing bandwidth usage as one such reason. You're right, for contributing a patch and/or commenting through github, it's we as in those that are bold enough to sign up on github. We also happily send patches or comments on the mailing list as usual; we as in those that are bold enough to post on public mailing lists. It's still an added value that a non-empty set of people are happy with. Now the situation is in theory not all that different with Savannah. Except that Savannah does not serve stockholders but its users and Free Software. When they find that there is a technical problem in connection with serving a project, pull the plug will be way lower in the list of remedies than with GitHub. Fortunately with git repos even if the hosting goes, the project's source code is still in hand, Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3 support
On Tue, Mar 18, 2014 at 12:44 PM, David Kastrup d...@gnu.org wrote: That's not quite the same as we already have hosting, a platform for contribution and review comments. Everything beyond the content in private repositories is gone if a project is removed. And we have is a bit of a euphemism for proprietary software run on a proprietary service with a proprietary data store for everything but the central repository itself. It's more like we are permitted to use. Of course, with Savannah we have the same situation regarding the we are permitted to use angle, but the motivations for the permission are different. That makes me feel more at home. Again, if you're keen on providing hosting elsewhere, why not go for it. My point of view says it is not worth it, yours differ. I'll be glad if we get back on thread. Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Python 3 support
On Tue, Mar 18, 2014 at 4:43 PM, Jeremiah Benham jjben...@chicagoguitar.com wrote: I have forked gub and have been working on it for a while now. https://github.com/jjbenham/gub It is very different now from https://github.com/gperciva/gub and the main master. I don't know how to contribute changes unless via per file basis. Then each patch would need to be tested. I have added support for gtk3 on mingw, darwin-x86 and linux-x86. I also upgraded many things like tar (this adds .xz support). This was all to support the denemo project. It would be nice to work with others on it. Jeremiah Hi Jeremiah, Thanks for reaching out. A while ago I noticed your fork and though that at some point it would be good to investigate what should be contributed back. Unfortunately it takes a lot of time to test changes in GUB, and I was already puzzled enough by the various different branches between Jan's and Graham's repos. I'm glad to hear that you would like to contribute your changes back, that will be a welcome collaboration. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Python 3 support
Hi, Our python scripts currently require a python2 interpreter with version at least 2.4, but by bumping the requirement to 2.6 we could start introducing from __future__ import print_function which will be one of the major step towards supporting both python2 and python3 interpreters with a single codebase. One of the big hurdle to bumping the python version requirement is our own cross-platform build system GUB which provides 2.4, but last summer I was able to build lilypond with an updated GUB, based on some experimental branch by Jan where I added a few commits. You can find the patchset here: https://github.com/gperciva/gub/pull/6 I think the following would be a good 1-2 punch approach for the current development cycle: First, upgrade python in GUB and make sure we can build current dev and stable branches of lilypond from it. Then bump the python requirement in the dev branch and start migrating to a codebase that supports python 2.6+ and python 3+ Thoughts? Objections? Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [translations] Re: 2.18 release plans (again).
On 27/10/2013 2:09 PM, Janek Warchoł wrote: That's good, but the most irritating thing about this patch is not that i have to solve merge conflicts. I'm mainly irritated because a piece of solid code (maybe it's not as solid as i think, but to know that i need _reviews_) is laying dormant for *half a year*, which prohibits me from working on some other stuff. I would really like to get some of my GSoC work finished and merged into master, and this patch is a first step for that. I'm curious, why is this issue set to Patch-waiting? I think generally people hardly ever have enough time to look at Patch-countdown issues, so a Patch-waiting issue would definitely not get much attention. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [translations] Re: 2.18 release plans (again).
On 29/10/2013 4:43 AM, David Kastrup wrote: Julien Rioux jri...@lyx.org writes: On 27/10/2013 2:09 PM, Janek Warchoł wrote: That's good, but the most irritating thing about this patch is not that i have to solve merge conflicts. I'm mainly irritated because a piece of solid code (maybe it's not as solid as i think, but to know that i need _reviews_) is laying dormant for *half a year*, which prohibits me from working on some other stuff. I would really like to get some of my GSoC work finished and merged into master, and this patch is a first step for that. I'm curious, why is this issue set to Patch-waiting? I had to go answer my own question: The patch contains code changes without the necessary doc changes, so it is not suitable for Patch-review state, but Janek would appreciate reviewer comments so that the code can reach a final form before doing the doc changes. I think generally people hardly ever have enough time to look at Patch-countdown issues, so a Patch-waiting issue would definitely not get much attention. Well, that's what Janek complained about. It's more or less a consequence of our grading system: Patch-review means slated to move to countdown and Patch-Countdown means slated to move to Patch-push. Patch-waiting seems like the correct qualifier. How about advertising those Patch-waiting issues as part of the Countdown email that is sent regularly? We currently have 7 of those, and could probably pretty quickly identify which one are truly waiting and which one are now abandoned. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Build: Fix compilation with GNU make 4.0 (issue 18700043)
Reviewers: John Mandereau, Message: Thanks to Thomas Klausner. This seems like the correct fix. Cheers, Julien Description: Build: Fix compilation with GNU make 4.0 Fix recipes commence before first target error. Patch from Thomas Klausner. Please review this at https://codereview.appspot.com/18700043/ Affected files (+1, -1 lines): M stepmake/stepmake/po-targets.make Index: stepmake/stepmake/po-targets.make diff --git a/stepmake/stepmake/po-targets.make b/stepmake/stepmake/po-targets.make index 8919dab8239e69f0378a0d6071fc1d249f8bbff0..8a0dd76053f51e8a7ef98f4e9b289a7e24c45218 100644 --- a/stepmake/stepmake/po-targets.make +++ b/stepmake/stepmake/po-targets.make @@ -37,10 +37,10 @@ ifneq ($(strip $(ALL_PO_SOURCES)),) --keyword=_ --keyword=_f --keyword=_i \ $(XGETTEXT_FLAGS) $(ALL_PO_SOURCES) endif -endif sed -i '1,2d' $(po-outdir)/$(package).po sed -i -e 's/^\# This file is distributed.*/$(sed-header)/' $(po-outdir)/$(package).po sed -i -e 's/^\Content-Type: text\/plain.*/$(sed-content)/' $(po-outdir)/$(package).po +endif po-update: po ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Build: Fix out-of-tree build from tarball. (issue 13854043)
https://codereview.appspot.com/13854043/diff/16001/Documentation/GNUmakefile File Documentation/GNUmakefile (right): https://codereview.appspot.com/13854043/diff/16001/Documentation/GNUmakefile#newcode283 Documentation/GNUmakefile:283: $(outdir)/contributor.texi: $(outdir)/ly-grammar.txt On 2013/10/02 09:34:19, dak wrote: The problem why this is creepier than the original rule is that notation.texi is a generated file (from notation.tely) while contributor.texi is an original file in our repository. $(outdir)/contributor.texi is a generated file (from contributor.texi; the rule is a simple copy). https://codereview.appspot.com/13854043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Build: Fix out-of-tree build from tarball. (issue 13854043)
https://codereview.appspot.com/13854043/diff/7001/Documentation/GNUmakefile File Documentation/GNUmakefile (right): https://codereview.appspot.com/13854043/diff/7001/Documentation/GNUmakefile#newcode283 Documentation/GNUmakefile:283: $(outdir)/contributor.texi: $(outdir)/ly-grammar.txt On 2013/10/01 10:27:08, dak wrote: As mentioned in the comments: I don't think that contributor.texi depends on ly-grammar.txt: it just has a @verbatiminclude of it inside. So it should be that whatever depends on contributor.texi would also depend on ly-grammar.txt. Concretely: contributor.texi does not need to get rebuilt when touching ly-grammar.txt. I don't see a worse problem, though. While that's technically true, my feeling is to go with the minimal change to get the least surprises. Since this used to refer to notation.texi, I simply changed it to notation.texi; this is easier to do than typing multiple dependency rules for each output format, and avoids the risk of missing one. https://codereview.appspot.com/13854043/diff/7001/Documentation/de/GNUmakefile File Documentation/de/GNUmakefile (right): https://codereview.appspot.com/13854043/diff/7001/Documentation/de/GNUmakefile#newcode11 Documentation/de/GNUmakefile:11: $(outdir)/notation.texi: $(outdir)/ly-grammar.txt On 2013/10/01 10:27:08, dak wrote: That gives us our own copy of ly-grammar.txt in the German documentation, right? right. https://codereview.appspot.com/13854043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Let convert-ly -d reflect last effective rather than last applied rule (issue 14077043)
lgtm Cheers, Julien https://codereview.appspot.com/14077043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add backup option to convert-ly (Issue 3572) (issue 14040043)
Again, can we add a check if there is already a numbered backup around? Make numbered backups for files that have numbered backups already. Otherwise, make single backups. This is the default. That would mean: https://codereview.appspot.com/14040043/diff/6001/scripts/convert-ly.py File scripts/convert-ly.py (right): https://codereview.appspot.com/14040043/diff/6001/scripts/convert-ly.py#newcode239 scripts/convert-ly.py:239: if numbered: if numbered or (os.path.exists(file + '.~1~') and os.path.isfile(file + '.~1~')): https://codereview.appspot.com/14040043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
scripts: improve strip-whitespace.py (issue 13720049)
LGTM. You might want to add to your comment at the top: Also convert the file to Unix line endings. https://codereview.appspot.com/13720049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add backup option to convert-ly (Issue 3572) (issue 14040043)
This suggestion from David sounded like a good default: Make numbered backups for files that have numbered backups already. https://codereview.appspot.com/14040043/diff/1/scripts/convert-ly.py File scripts/convert-ly.py (right): https://codereview.appspot.com/14040043/diff/1/scripts/convert-ly.py#newcode243 scripts/convert-ly.py:243: back_up = file + '.' + str(n) + '~' Should we go with what David suggested: file.ly.~1~ etc. https://codereview.appspot.com/14040043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Build everything on the first pass of make. (issue 13333048)
On Thu, Sep 12, 2013 at 5:47 AM, Phil Holmes m...@philholmes.net wrote: I don't understand what you're fixing here, Julien. On my machine, deleting the build directory completely, then recreating it and running make (-j9 of course) completely rebuilds the binaries in a single pass. Further immediate calls to make do nothing. Good to know, but here it doesn't work out quite like this. For me the emmentaler font files are being rebuilt on the second call to make. Somehow it thinks that the fontforge script files are newer than the font files, so it rebuilds the font files. I'll attach the log below. The patch fixes this. For make doc, a bunch of stuff is rebuilt on second pass, but fixing all this is hard to track. The only significant bug in this area that I'm aware of is that modifying metafont files does not cause the font files to be rebuilt - we have to do some deleting in build/mf/out to force a rebuild. Yep, that's bug 779: http://code.google.com/p/lilypond/issues/detail?id=779 John was working on it, it seems, but probably got sidetracked. Cheers, Julien jrioux@camel ~/git/lilypond (master)$ git checkout master Already on 'master' jrioux@camel ~/git/lilypond (master)$ git pull Already up-to-date. jrioux@camel ~/git/lilypond (master)$ rm -rf build jrioux@camel ~/git/lilypond (master)$ mkdir build jrioux@camel ~/git/lilypond (master)$ ./autogen.sh --noconf /dev/null jrioux@camel ~/git/lilypond (master)$ cd build jrioux@camel ~/git/lilypond/build (master)$ ../configure --disable-optimising /dev/null jrioux@camel ~/git/lilypond/build (master)$ make /dev/null jrioux@camel ~/git/lilypond/build (master)$ make -n make --no-builtin-rules -C scripts/build make[1]: Entering directory `/home/jrioux/git/lilypond/build/scripts/build' true make[1]: Leaving directory `/home/jrioux/git/lilypond/build/scripts/build' make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C python all make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C scripts all make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C flower all make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C lily all make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C mf all make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C ly all make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C tex all make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C ps all make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C scm all make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C po all make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C elisp all make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C vim all make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C input all make --no-builtin-rules PACKAGE=LILYPOND package=lilypond -C Documentation all true make[1]: Entering directory `/home/jrioux/git/lilypond/build/python' make PACKAGE=LILYPOND package=lilypond -C auxiliar all true make[2]: Entering directory `/home/jrioux/git/lilypond/build/python/auxiliar' true make[2]: Leaving directory `/home/jrioux/git/lilypond/build/python/auxiliar' make[1]: Leaving directory `/home/jrioux/git/lilypond/build/python' make[1]: Entering directory `/home/jrioux/git/lilypond/build/scripts' make PACKAGE=LILYPOND package=lilypond -C build man true make[2]: Entering directory `/home/jrioux/git/lilypond/build/scripts/build' true make[2]: Leaving directory `/home/jrioux/git/lilypond/build/scripts/build' make PACKAGE=LILYPOND package=lilypond -C build all true make[2]: Entering directory `/home/jrioux/git/lilypond/build/scripts/build' true make[2]: Leaving directory `/home/jrioux/git/lilypond/build/scripts/build' make[1]: Leaving directory `/home/jrioux/git/lilypond/build/scripts' make[1]: Entering directory `/home/jrioux/git/lilypond/build/flower' true make[1]: Leaving directory `/home/jrioux/git/lilypond/build/flower' make[1]: Entering directory `/home/jrioux/git/lilypond/build/lily' true true make[1]: Leaving directory `/home/jrioux/git/lilypond/build/lily' make[1]: Entering directory `/home/jrioux/git/lilypond/build/mf' cd ./out /usr/local/bin/fontforge -script emmentaler-11.pe cd ./out /usr/local/bin/fontforge -script emmentaler-13.pe cd ./out /usr/local/bin/fontforge -script emmentaler-14.pe cd ./out /usr/local/bin/fontforge -script emmentaler-16.pe cd ./out /usr/local/bin/fontforge -script emmentaler-18.pe cd ./out /usr/local/bin/fontforge -script emmentaler-20.pe cd ./out /usr/local/bin/fontforge -script emmentaler-23.pe make -C /home/jrioux/git/lilypond/build link-mf-tree make[2]: Entering directory `/home/jrioux/git/lilypond/build' make[2]: Nothing to be done for `link-mf-tree'. make[2]: Leaving directory `/home/jrioux/git/lilypond/build' true make[1]: Leaving directory `/home/jrioux/git/lilypond/build/mf' make[1]: Entering directory `/home/jrioux/git/lilypond/build/ly' true make[1]: Leaving directory
Build dependencies for metafont files (issue 779). (issue 13681043)
Reviewers: John Mandereau, Message: Please review. Description: Build dependencies for metafont files (issue 779). Write .dep files containing make dependency rules for .mf files, allowing to simply type `make' to process the fonts after changing an input'ed file and have the fonts updated with the minimum amount of processing. These .dep files are generated by recursively scanning for lines of the form input X; in the .mf files, and looking up these input'ed files within the mf source directory. The .dep files are included into the build by stepmake/generic-targets.make. http://code.google.com/p/lilypond/issues/detail?id=779 Please review this at https://codereview.appspot.com/13681043/ Affected files (+24, -3 lines): M stepmake/stepmake/metafont-rules.make M stepmake/stepmake/metafont-vars.make Index: stepmake/stepmake/metafont-rules.make diff --git a/stepmake/stepmake/metafont-rules.make b/stepmake/stepmake/metafont-rules.make index 5b6ad17d91a0a204a1470509e61ea3cdac5e19e7..5be005a1985dc7e998a0d85df79b40c48f4784fe 100644 --- a/stepmake/stepmake/metafont-rules.make +++ b/stepmake/stepmake/metafont-rules.make @@ -2,13 +2,13 @@ # we want to see botched results as well. $(outdir)/%.dvi: %.mf - -MFINPUTS=$(src-dir) $(METAFONT) \scrollmode; input $; + -$(DO_MF_DEP) MFINPUTS=$(src-dir) $(METAFONT) \scrollmode; input $; gftodvi $(basename $) mv $(basename $).dvi $(outdir) rm $(basename $).*gf $(outdir)/%.tfm $(outdir)/%.log: %.mf - MFINPUTS=$(src-dir) $(METAFONT) \mode:=$(MFMODE); nonstopmode; input $; $(METAFONT_QUIET) + $(DO_MF_DEP) MFINPUTS=$(src-dir) $(METAFONT) \mode:=$(MFMODE); nonstopmode; input $; $(METAFONT_QUIET) # Let's keep this log output, it saves another mf run. mv $(basename $(@F)).log $(basename $(@F)).tfm $(outdir) rm -f $(basename $(@F)).*gf $(basename $(@F)).*pk @@ -19,7 +19,7 @@ $(outdir)/%.tfm $(outdir)/%.log: %.mf # the soft link for mf2pt1.mp is for recent mpost versions # which no longer dump a .mem file $(outdir)/%.pfb: %.mf $(outdir)/mf2pt1.mem $(outdir)/%.log - TMP=`mktemp -d $(outdir)/pfbtemp.$*.X` \ + $(DO_MF_DEP) TMP=`mktemp -d $(outdir)/pfbtemp.$*.X` \ ( cd $$TMP \ ln -s ../mf2pt1.mem . \ ln -s ../../mf2pt1.mp . \ Index: stepmake/stepmake/metafont-vars.make diff --git a/stepmake/stepmake/metafont-vars.make b/stepmake/stepmake/metafont-vars.make index aeb75c5f004cf1ab1da0e78b985dfdd93dab11be..73f35a53ed68cd0490ccaa367b5f58fe83739492 100644 --- a/stepmake/stepmake/metafont-vars.make +++ b/stepmake/stepmake/metafont-vars.make @@ -15,3 +15,24 @@ METAFONT_QUIET = /dev/null else METAFONT_QUIET = endif + +# Find the metafont file $(1) within the source dirs and return its path. +# If not found, return $(outdir)/$(1) assuming that it is a generated file. +find-mf = \ +$(firstword \ + $(wildcard $(src-dir)/$(1)) \ + $(wildcard $(top-src-dir)/mf/$(1)) \ + $(outdir)/$(1) \ +) + +# Recursively scan the metafont .mf file $(1) for input X; +# and return all dependencies. +scan-mf = \ +$(foreach f, $(shell test -f $(1) sed -ne /^[[:space:]]*input[[:space:]]/s/^[[:space:]]*input\([^.;]*\)\(.mf;\|;\)/\1.mf/p $(1)), \ + $(call find-mf,$(f)) \ + $(call scan-mf,$(call find-mf,$(f))) \ +) + +# Find dependencies for the target $@, based on the metafont source file $, +# and write the dependencies to a .dep file. +DO_MF_DEP = ( echo ./$@: $(call scan-mf,$) $(basename $@).dep ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ERROR: Please install required programs: International New Century Schoolbook fonts
On 12/09/2013 6:09 PM, Federico Bruni wrote: 2013/8/3 Federico Bruni fedel...@gmail.com mailto:fedel...@gmail.com I'm getting this error if I run ./autogen.sh in git master: ERROR: Please install required programs: International New Century Schoolbook fonts International New Century Schoolbook fonts I can't find the missing package, I have all the ones listes in the CG. What I'm missing? In the same directory, now it works if I checkout master branch and I still get this error if I checkout translation branch. Probably issue 3526 fixed by Julien? Yes. Given multiple sets of installed Century fonts, ./configure now tries to find one that does have the Cyrillic characters. Previously, it would just take the first font location it could find, check that it had Cyrillic characters, and bomb out when it didn't, without checking the alternative locations for the font. I presume this fix hasn't made it into the translation branch yet. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: getting fc-list to see gsfonts
On 11/09/2013 3:28 AM, Mark Polesky wrote: So, after Julien's patch https://codereview.appspot.com/13390043 I finally get a proper error at the configure stage: ERROR: Please install required programs: International New Century Schoolbook fonts (make sure the fc-list utility can see them, or use --with-ncsb-dir) See INSTALL.txt for more information on how to build LilyPond Great. This patch is going in so everyone will benefit. After a lot of searching, I realized that all I needed was ../configure --with-ncsb-dir=/usr/share/fonts/type1/gsfonts/ and now my fonts work (finally!). But now I'm curious, how do I get fc-list to see the fonts in the gsfonts directory? Looks like you have to run fc-cache to update the database. Something like: sudo fc-cache -fsv Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Restore the default `make' target. (issue 13290047)
Updated to be purely documentational. https://codereview.appspot.com/13290047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Disallow metapost versions 1.504 x 1.803. (issue 13413046)
Reviewers: dak, lemzwerg, Message: Please review. Description: Disallow metapost versions 1.504 x 1.803. Add a check in ./configure to avoid these buggy versions of metapost: 1.504 mpost --version 1.803 Fixes issue 3539: Configure should forbid mpost 1.802 from TexLive 2013 http://code.google.com/p/lilypond/issues/detail?id=3539 Please review this at https://codereview.appspot.com/13413046/ Affected files (+8, -0 lines): M aclocal.m4 Index: aclocal.m4 diff --git a/aclocal.m4 b/aclocal.m4 index 87d8474316adf7dced50154d180d117ff572ac0a..8c03fcc196e45944256ec47ecbe7cf0900d8b0df 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -1167,6 +1167,14 @@ AC_DEFUN(STEPMAKE_TEXMF_DIRS, [ AC_DEFUN(STEPMAKE_TEXMF, [ STEPMAKE_PROGS(METAFONT, mf-nowin mf mfw mfont, $1) STEPMAKE_PROGS(METAPOST, mpost, $1) +if test $METAPOST != ; then + ver=`STEPMAKE_GET_VERSION($METAPOST)` + num=`STEPMAKE_NUMERIC_VERSION($ver)` + # Avoid buggy metapost versions: 1.504 x 1.803 + if test $num -gt 1504000 -a $num -lt 1803000; then +STEPMAKE_ADD_ENTRY($1, [mpost (due to a bug in metapost, versions 1.504 x 1.803 are not supported; installed: $ver)]) + fi +fi AC_MSG_CHECKING(for working metafont mode) modelist='ljfour lj4 lj3 lj2 ljet laserjet' ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Build everything on the first pass of make. (issue 13333048)
Reviewers: John Mandereau, lemzwerg, Message: Please review. Description: Build everything on the first pass of make. Everything should be built and up-to-date after a one-shot `make' call. Currently, this is not the case: fonts are being rebuilt on the secnod pass. This required a dependency fix for emmentaler fonts. The dependencies are ordered so that fonts aren't rebuilt on a subsequent call to make. For one-shot `make doc', we also have issues, and things are a bit more difficult to track down. Dependencies for web.texi in translated languages are fixed. Please review this at https://codereview.appspot.com/1048/ Affected files (+5, -4 lines): M make/doc-i18n-root-rules.make M mf/GNUmakefile Index: make/doc-i18n-root-rules.make diff --git a/make/doc-i18n-root-rules.make b/make/doc-i18n-root-rules.make index d374e5ca7339d97b03dace3d413b210eb5ee2174..a8e7ab5edef58af094481bc22cf685056b893d43 100644 --- a/make/doc-i18n-root-rules.make +++ b/make/doc-i18n-root-rules.make @@ -2,7 +2,7 @@ .SUFFIXES: .html .info .texi .texinfo # Explicitly list the dependencies on generated content -$(outdir)/web.texi: $(outdir)/weblinks.itexi +$(outdir)/web.texi: $(outdir)/we-wrote.itexi $(outdir)/others-did.itexi $(outdir)/weblinks.itexi $(top-build-dir)/Documentation/$(outdir)/%/index.$(ISOLANG).html: $(outdir)/%/index.html $(TRANSLATION_LILY_IMAGES) mkdir -p $(dir $@) Index: mf/GNUmakefile diff --git a/mf/GNUmakefile b/mf/GNUmakefile index f81b56dabef7f8de1bd4cd73b9bec5c7670b21bd..325bf8f9c97a464105822c873f14cddbfc7fd76f 100644 --- a/mf/GNUmakefile +++ b/mf/GNUmakefile @@ -99,9 +99,10 @@ $(PE_SCRIPTS): $(buildscript-dir)/gen-emmentaler-scripts $ --dir=$(outdir) -# Make tfm files first, log files last, -# so that normally log files aren't made twice -ALL_GEN_FILES = $(LOG_FILES) \ +# Generate emmentaler-*.pe scripts first, and *.otf, *.svg, *.woff files last, +# so that normally these files aren't regenerated on a subsequent call to make. +ALL_GEN_FILES = $(PE_SCRIPTS) \ + $(LOG_FILES) \ $(ENC_FILES) \ $(LISP_FILES) \ $(OTF_TABLES) \ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Restore the default `make' target. (issue 13290047)
On 2013/09/11 18:54:01, Mark Polesky wrote: personally, I would find this wording more intuitive: same as `make all', but restricted to the current directory Sounds good. Although... I guess `make local-all' and `make default' do the same thing? Maybe you could just say same as `make local-all' There isn't a local-all target (although `make help' hints that there should be). hmm, should probably corrcet this as well. Cheers, Julien https://codereview.appspot.com/13290047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: getting fc-list to see gsfonts
On 11/09/2013 2:38 PM, Mark Polesky wrote: Julien Rioux wrote: But now I'm curious, how do I get fc-list to see the fonts in the gsfonts directory? Looks like you have to run fc-cache to update the database. Something like: sudo fc-cache -fsv Julien and David, I'll start by reiterating that my build now works fine, as long as I do: ../configure --with-ncsb-dir=/usr/share/fonts/type1/gsfonts/ So, I have a successful workaround. And yes David, I manually applied Julien's patch before he pushed it. Now I'm simply curious to see how I can get fc-list to see the fonts. Julien, I tried both of these: sudo fc-cache -fsv sudo fc-cache -fsv /usr/share/fonts/type1/gsfonts/ With both commands, I get output that contains this: /usr/share/fonts/type1/gsfonts: caching, new cache contents: 35 fonts, 0 dirs /var/cache/fontconfig: cleaning cache directory fc-cache: succeeded And yet fc-list | grep entury returns nothing, even after rebooting. I have the same problem (fc database not updating). I'm not sure how to update this fc-list stuff, but it seemed to me that fc-cache is the command we want to use for it, though, it doesn't seem to work here either. Julien, I'd like to make a suggestion. In the error message, I think it would be far more helpful if instead of this or use --with-ncsb-dir it said something like this or use `configure --with-ncsb-dir=PATH_TO_GSFONTS_DIR' The point is that it is not at all intuitive to know that gsfonts is the source of the New Century Schoolbook files. Well, it's not clear that gsfonts is the correct directory for everyone. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: ./test-patchy on steroids
On Wed, Sep 11, 2013 at 6:19 PM, James pkx1...@gmail.com wrote: Julien, I just had a bit of a shock when I ran the test-patchy script - then realized that I had inadvertently added an extra character before running the script --snip-- jlowe@jlowe26vm ~/lilypond-extra/patches (master)$ ./test-patches.py ] issues [3539, 3521, 3473, 3256, 3194, 3192, 3166, 3086, 3056, 3047, 3031, 3026, 3003, 2998, 2968, 2893, 2830, 2801, 2736, 2683, 2681, 2658, 2647, 2646, 2594, 2586, 2535, 2474, 2473, 2411, 2368, 2236, 2230, 2207, 2141, 2091, 2082, 2066, 2026, 2009, 1908, 1434, 1380, 1370, 1351, 1333, 1278, 1269, 1228, 1107, 1093, 1030, 1005, 990, 971, 822, 694, 657, 601, 539, 355, 318, 34] The interface to test-patches.py allow you to specify a series of issue numbers on the command line. The command-line parameters are passed to a search query on the issue page. The list you are getting is definitely weird, but it matches what the issue page returns for a id:] query: http://code.google.com/p/lilypond/issues/list?q=id%3A] I have no idea how that makes senses. --snip-- ;) Thought maybe David had gone on some bug-fix rampage! James Nice! Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Restore the default `make' target. (issue 13290047)
Reviewers: dak, Message: On 2013/09/06 16:39:24, dak wrote: https://codereview.appspot.com/13290047/diff/1/stepmake/stepmake/generic-targets.make File stepmake/stepmake/generic-targets.make (right): https://codereview.appspot.com/13290047/diff/1/stepmake/stepmake/generic-targets.make#newcode1 stepmake/stepmake/generic-targets.make:1: .PHONY : all clean bin-clean default dist exe help html lib man TAGS\ That change might be independently useful. https://codereview.appspot.com/13290047/diff/1/stepmake/stepmake/generic-targets.make#newcode5 stepmake/stepmake/generic-targets.make:5: default: all I have no idea what makes you think that default is not a defined target for most Makefiles. git grep ^default: turns up a host of default targets. Documentation/GNUmakefile:default: local-txt-doc Documentation/css/GNUmakefile:default: Documentation/logo/GNUmakefile:default: $(lilypond-icon) $(ly-icon) Documentation/misc/GNUmakefile:default: local-txt-doc Documentation/pictures/GNUmakefile:default: GNUmakefile.in:default: $(config_h) build-dir-setup build-scripts lily/GNUmakefile:default: make/abc-targets.make:default: make/doc-i18n-root-targets.make:default: make/lilypond-book-targets.make:default: make/midi-targets.make:default: make/musicxml-targets.make:default: mf/GNUmakefile:default: $(ALL_GEN_FILES) \ po/GNUmakefile:default: $(MO_FILES) python/GNUmakefile:default: $(outdir)/relocate-preamble.py python/auxiliar/GNUmakefile:default: stepmake/stepmake/automatically-generated.sub.make:default: stepmake/stepmake/documentation-targets.make:default: stepmake/stepmake/executable-targets.make:default: $(EXECUTABLE) stepmake/stepmake/help2man-targets.make:default: man stepmake/stepmake/library-targets.make:default: $(LIBRARY) stepmake/stepmake/python-module-targets.make:default: $(OUT_PY_MODULES) $(OUT_PY stepmake/stepmake/shared-library-targets.make:default: $(SHARED_LIBRARY) stepmake/stepmake/texinfo-targets.make:default: $(INFO_FILES) stepmake/stepmake/topdocs-targets.make:default: local-txt-doc So you should likely check which particular Makefile is missing a default target and double-check by trying make default since there are a lot of opportunities for having the default target defined in an include file. I was confused. default exists, it's just not what I expected after reading the description: the empty target is equivalent to `make all' (which recurses through all subdirectories) and not `make default' (which acts in the local directory only). I'll turn this issue into a documentation one, changing what `make help' has to say about the default target. Cheers, Julien Description: Restore the default `make' target. `make help' mentions that `default' is the same as the empty target, but it's not even a defined target. This commit restores `default' as the default, empty target. Please review this at https://codereview.appspot.com/13290047/ Affected files (+4, -2 lines): M stepmake/stepmake/generic-targets.make Index: stepmake/stepmake/generic-targets.make diff --git a/stepmake/stepmake/generic-targets.make b/stepmake/stepmake/generic-targets.make index 1b998b938dfc3eb6b2c0bbb13dc0aa1c06be10e3..6837bf5558a7411b5fd7dc187b0114bc813aa47f 100644 --- a/stepmake/stepmake/generic-targets.make +++ b/stepmake/stepmake/generic-targets.make @@ -1,8 +1,10 @@ -.PHONY : all clean bin-clean default dist exe help html lib TAGS\ +.PHONY : all clean bin-clean default dist exe help html lib man TAGS\ po doc doc-stage-1 WWW-1 WWW-2 WWW-post local-WWW-1 local-WWW-2\ log-clean -all:default +default: all + +all: $(LOOP) man: ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Keep bison-generated files in sync. (issue 13466043)
See http://code.google.com/p/lilypond/issues/detail?id=3528 https://codereview.appspot.com/13466043/diff/2001/stepmake/stepmake/c++-rules.make File stepmake/stepmake/c++-rules.make (right): https://codereview.appspot.com/13466043/diff/2001/stepmake/stepmake/c++-rules.make#newcode16 stepmake/stepmake/c++-rules.make:16: $(BISON) -o $(subst .hh,.cc,$@) -d $ On 2013/09/02 17:46:15, dak wrote: Han-Wen's version was slightly different: $(BISON) -d -o $(subst .hh,.cc,$@) $ but I don't consider it graceful. I'd try $(BISON) -d -o $*.cc $ instead. I _think_ this should take the right directory. The ordering of -d and -o options doesn't matter, so it was exactly the same. We can use $* if you prefer, but let's not forget the output dir, so $(BISON) -d -o $(outdir)/$*.cc $ OK? https://codereview.appspot.com/13466043/diff/2001/stepmake/stepmake/c-rules.make File stepmake/stepmake/c-rules.make (right): https://codereview.appspot.com/13466043/diff/2001/stepmake/stepmake/c-rules.make#newcode16 stepmake/stepmake/c-rules.make:16: $(BISON) -o $(subst .h,.c,$@) -d $ On 2013/09/02 17:46:15, dak wrote: Do we need this rule at all? We don't have .y files in the tree and the only actual C file would appear to be python/midi.c anyway. It is part of stepmake, and it is conceivable (although I wouldn't wish it on anyone) that somebody has decided to use stepmake for their own project. (lilypond doesn't use this rule) https://codereview.appspot.com/13466043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Since Bison is optional, need to distribute Documentation/out/ly-grammar.txt (issue 13475043)
LGTM https://codereview.appspot.com/13475043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch to remove unused header tie-column-format.hh
On 21/08/2013 12:32 AM, Frédéric Bron wrote: Please read http://www.lilypond.org/doc/v2.17/Documentation/contributor-big-page.html#summary-for-experienced-developers and start using git-cl. Plain patches posted to -devel tend to get forgotten in mist of syntax changes and font standards debates. I know but there is no issue in the tracker for this. Could you create one? Frédéric git-cl will create the issue for you when you upload your patch. If it doesn't, please report it as a bug. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Windows tutorial updates (issue 12980044)
On 2013/08/17 12:29:08, Julien Rioux wrote: It looks like we can download individual patches for each file, so maybe we can use this with Patchy somehow, I've updated Patchy to handle the too large to download patchset. You can review here: https://github.com/gperciva/lilypond-extra/pull/14 or grab a full copy here: https://github.com/jrioux/lilypond-extra/archive/rietveld.zip I've updated git-cl again to also handle these too large patchsets when doing git cl patch 12980044. Review here: https://github.com/gperciva/git-cl/pull/3 or grab a full copy here: https://github.com/jrioux/git-cl/archive/rietveld.zip I hope this will make reviewing Phil's work easier. Cheers, Julien https://codereview.appspot.com/12980044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: colorful make output! yum!
On 20/08/2013 9:00 AM, Phil Holmes wrote: However, I (and, from what I've seen, David K, and almost certainly Graham and probably Julien) would strongly oppose adding extra complexity to the already over-complex build system. I actually don't mind this, provided I can turn it off. I think it's getting more bad reviews than it is deserved, and if it had been submitted has a patch in the standard way it probably would have gone under the radar. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: patch to remove unused header tie-column-format.hh
On 20/08/2013 3:00 PM, Frédéric Bron wrote: Dear all, The header tie-column-format.hh is unused. tie-column-format.cc was removed in 2.10 and removing the header does not prevent lilypond to build. Only 2 files were including it without actually using it. Here is the proposed patch. Frédéric Please read http://www.lilypond.org/doc/v2.17/Documentation/contributor-big-page.html#summary-for-experienced-developers and start using git-cl. Plain patches posted to -devel tend to get forgotten in mist of syntax changes and font standards debates. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Windows tutorial updates (issue 12980044)
On 2013/08/17 11:31:41, PhilEHolmes wrote: The patch set on Rietveld now includes the new images (thanks, Julien). hmm, the images are there, we can see them in the side-by-side diffs... but for the patch, Rietveld says Patch set is too large to download. Bummer. It looks like we can download individual patches for each file, so maybe we can use this with Patchy somehow, but for now Patchy still won't be able to test this. Anyway, thanks for trying. Cheers, Julien https://codereview.appspot.com/12980044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make website fails on platforms where python3 is the default. (issue 12769043)
Reviewers: janek, Graham Percival, Message: On 2013/08/16 04:45:59, Graham Percival wrote: When building with WEBSITE_ONLY_BUILD, $(PYTHON) will default to python (as defined at the top of the file). We do that because we don't run ./configure on the web server. I _think_ this will be safe enough, but it might be nice to change the upper definition to $(PYTHON) = python2 I did not touch that part specifically because I do not want to break anything with the current machine that runs this build. Is there a python2 on the host machine where this command would normally be run? AFAIK the python2 alias is only installed if python3 is also installed on the system, which might or might not be the case. Cheers, Julien Description: make website fails on platforms where python3 is the default. Use the python found by ./configure to build the website. Please review this at https://codereview.appspot.com/12769043/ Affected files: M make/website.make Index: make/website.make diff --git a/make/website.make b/make/website.make index bf3b2ad865d747ef26375efc3f96e272fa7499a3..3e8df628d564f956f0be839224a947ae082b1c54 100644 --- a/make/website.make +++ b/make/website.make @@ -68,11 +68,11 @@ EXTRACT_TEXI_FILENAMES=$(PYTHON) $(script-dir)/extract_texi_filenames.py $(quiet -I $(dir $) \ -I $(OUT) \ -o $(OUT) -CREATE_VERSION=python $(script-dir)/create-version-itexi.py -CREATE_WEBLINKS=python $(script-dir)/create-weblinks-itexi.py -MASS_LINK=python $(script-dir)/mass-link.py -WEB_POST=python $(script-dir)/website_post.py -WEB_BIBS=python $(script-dir)/bib2texi.py +CREATE_VERSION=$(PYTHON) $(script-dir)/create-version-itexi.py +CREATE_WEBLINKS=$(PYTHON) $(script-dir)/create-weblinks-itexi.py +MASS_LINK=$(PYTHON) $(script-dir)/mass-link.py +WEB_POST=$(PYTHON) $(script-dir)/website_post.py +WEB_BIBS=$(PYTHON) $(script-dir)/bib2texi.py EXAMPLES=$(LILYPOND_WEB_MEDIA_GIT)/ly-examples PICTURES=$(LILYPOND_WEB_MEDIA_GIT)/pictures ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Support for testing min and max versions of Guile. (issue 11303044)
On Mon, Jul 22, 2013 at 1:18 PM, Graham Percival gra...@percival-music.cawrote: On Mon, Jul 22, 2013 at 02:03:31PM +, d...@gnu.org wrote: As far as I know, 1.9 is the development series culminating in the stable 2.0, so while 1.9 is not all too likely to be installed on current systems, allowing/preferring it over 1.8 is not going to be helpful. I think the cutoff point should be at 1.9. Good point. I'll make sure to make the change before committing. Do we have an override option for those people who actually want to develop towards 2.0 or are they supposed to edit the autoconf files? Don't we have a separate branch for guile-2.0? If not, we should, and that branch can change the numbers to guile 2.0 or higher. (or 2.x if we rely on any more recent guile features or bugfixe) One overrides these auto settings in the usual way, setting GUILE=/path/to/guile etc on the command line. And as you have seen, once we are ready for guile 2, it's a one-line change in configure.ac Should we document this somewhere? I think the commit message, pointing to the relevant tracker issue and code review, should be sufficient. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fedora 19 comes with guile 2.0.9 - cannot use 2.17.22
On 20/07/2013 5:00 PM, Ian Hulin wrote: On 13/07/13 20:51, Frédéric Bron wrote: I don't think ./configure should do this automatically, but at the very least, it should fail when it finds a guile version that is incompatible with our source code. Can you please open an issue for it\? good point, I will do that. Frédéric Hi Frédéric, Could you make the Guile-1 compatibility a separate issue from 3382, which is about tex-info versions? These are different issues, I don't think there was ever any confusion about that. Frédéric sent a very clear message to lilypond-bugs about it. Here's a suggestion: add an --enable-guile-1-compatibilty option defaulting to #t until the Guile 2 conversion cut-over. If set to true this sets up the variables you mentioned to be exported in make. Once the Guile-2 conversion is complete, we reverse the default for --enable-guile-1-compatibilty to #f. aclocal.m4 is the bit which does the configure option parsing, We'd need new internal variable guile_1_compatibility_b which then controls declaring if test $guile_1_compatibility_b = yes; then AC_DEFINE(GUILE_1_COMPATIBILITY) DEFINES=$DEFINES -DGUILE_1_COMPATIBILITY GUILE= /usr/bin/guile1.8 GUILE_CONFIG= /usr/bin/guile1.8-config GUILE_TOOLS= /usr/bin/guile1.8-tools fi This is untested but you get the idea. Model the changes for aclocal.m4 on the --enable-optimising/($)optimising_b sections. I haven't looked at what would be needed in the makefiles but this should give you or Julien a start. I got started already, see http://code.google.com/p/lilypond/issues/detail?id=3461. I don't think that we need a guile-1 compatibility mode right now, since we don't even support guile-2 yet and dropping guile-1 seems pretty far on the horizon. -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unable to run test patchy - URI changed for tracker?
On 18/07/2013 2:39 AM, Graham Percival wrote: On Wed, Jul 17, 2013 at 03:48:52PM +0100, Phil Holmes wrote: Three options I can think of. 1) use something other than Google. [...] 3) Screen scrape. I'd be seriously concerned about breakage. That said, it wouldn't be too bad if we used a fixed format like PATCHY: info to be parsed\n \n for all updates. - Graham I tried the scraping idea out, and it wasn't too bad to set up. Might be good for a temporary fix at least. The result is at https://github.com/gperciva/lilypond-extra/pull/12 -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unable to run test patchy - URI changed for tracker?
On 18/07/2013 11:00 AM, Phil Holmes wrote: - Original Message - From: Julien Rioux jri...@lyx.org To: lilypond-devel@gnu.org Sent: Thursday, July 18, 2013 3:50 PM Subject: Re: Unable to run test patchy - URI changed for tracker? On 18/07/2013 2:39 AM, Graham Percival wrote: On Wed, Jul 17, 2013 at 03:48:52PM +0100, Phil Holmes wrote: Three options I can think of. 1) use something other than Google. [...] 3) Screen scrape. I'd be seriously concerned about breakage. That said, it wouldn't be too bad if we used a fixed format like PATCHY: info to be parsed\n \n for all updates. - Graham I tried the scraping idea out, and it wasn't too bad to set up. Might be good for a temporary fix at least. The result is at https://github.com/gperciva/lilypond-extra/pull/12 -- Julien LGTM as a way of getting a list of issues, but I'm still unsure how the issue labels would be updated, since this requires a logged-in project member. -- Phil Holmes The comment updates using accept-patch.py and reject-patch.py aren't broken (yet), so let's hope it stays this way. -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unable to run test patchy - URI changed for tracker?
On 18/07/2013 11:46 AM, James wrote: On 18/07/13 16:08, Phil Holmes wrote: - Original Message - From: Julien Rioux jri...@lyx.org To: lilypond-devel@gnu.org Sent: Thursday, July 18, 2013 4:04 PM Subject: Re: Unable to run test patchy - URI changed for tracker? On 18/07/2013 11:00 AM, Phil Holmes wrote: - Original Message - From: Julien Rioux jri...@lyx.org To: lilypond-devel@gnu.org Sent: Thursday, July 18, 2013 3:50 PM Subject: Re: Unable to run test patchy - URI changed for tracker? On 18/07/2013 2:39 AM, Graham Percival wrote: On Wed, Jul 17, 2013 at 03:48:52PM +0100, Phil Holmes wrote: Three options I can think of. 1) use something other than Google. [...] 3) Screen scrape. I'd be seriously concerned about breakage. That said, it wouldn't be too bad if we used a fixed format like PATCHY: info to be parsed\n \n for all updates. - Graham I tried the scraping idea out, and it wasn't too bad to set up. Might be good for a temporary fix at least. The result is at https://github.com/gperciva/lilypond-extra/pull/12 -- Julien LGTM as a way of getting a list of issues, but I'm still unsure how the issue labels would be updated, since this requires a logged-in project member. -- Phil Holmes The comment updates using accept-patch.py and reject-patch.py aren't broken (yet), so let's hope it stays this way. -- Julien So - LGTM, although I've only briefly eyeballed it. Can you push to the main lilypond-extra repo so James can pull and test it on his machine? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel I can test this now if someone pushes it. James Done. -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issues building documentation on Fedora 19
On 13/07/2013 3:19 PM, Frédéric Bron wrote:
I can now build lilypond and compile at least the simple score { c }
But when I do my build process:
export GUILE=/usr/bin/guile1.8
export GUILE_CONFIG=/usr/bin/guile1.8-config
export GUILE_TOOLS=/usr/bin/guile1.8-tools
sh autogen.sh --noconfigure
mkdir build
cd build
../configure
make -j8 CPU_COUNT=8
I get the following errors:
Please check the logfile usage.makeinfo.log for errors
Please check the logfile contributor.makeinfo.log for errors
The files are attached and if I remove the warnings, this is what remains:
./build-2013-07-11/Documentation/usage.makeinfo.log:
out/usage/lilypond-book.texi:1179: @itemx must follow @item
out/usage/lilypond-book.texi:1183: @itemx must follow @item
out/usage/lilypond-book.texi:1187: @itemx must follow @item
out/usage/lilypond-book.texi:1192: @itemx must follow @item
out/usage/lilypond-book.texi:1201: @itemx must follow @item
out/usage/lilypond-book.texi:1205: @itemx must follow @item
out/usage/lilypond-book.texi:1210: @itemx must follow @item
out/usage/lilypond-book.texi:1233: @itemx must follow @item
./build-2013-07-11/Documentation/contributor.makeinfo.log:
/home/fred/lilypond/Documentation/included/compile.itexi:925: raising
the section level of @unnumberedsubsubsec which is too low
I wonder if texi2html version in F19 is too new? I have version 1.82 installed.
Not texi2html, but recent texinfo causes problems. The patch is ready
and I just need to push it. See
http://code.google.com/p/lilypond/issues/detail?id=3382
Cheers,
Julien
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fedora 19 comes with guile 2.0.9 - cannot use 2.17.22
On 13/07/2013 6:52 AM, Frédéric Bron wrote: I read also that: The packages will have to be patched to Require and BuildRequire the compat-guile18(-devel) package. Furthermore, they will have to be patched (if necessary) to use the renamed autotools macros. The patches to spec files and autotools macros are easy to implement. Packages that are already built will not have to be rebuilt (there are no soname bumps in the compat package) and should function without any problems. Only new releases will have to be patched. This confirms that lilypond cannot be built without modification. I just have to find these easy to implement patches... If someone has ideas! I found in the src rpm what to do: export GUILE=/usr/bin/guile1.8 export GUILE_CONFIG=/usr/bin/guile1.8-config export GUILE_TOOLS=/usr/bin/guile1.8-tools that works now! Any possibility to do that automatically in configure? Frédéric I don't think ./configure should do this automatically, but at the very least, it should fail when it finds a guile version that is incompatible with our source code. Can you please open an issue for it\? Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Images from Liedboek with attribution
On 12/06/2013 2:27 PM, James wrote: Nice. But where are the images of the score? ;) http://www.liedboek.nl/voorbeelden/proefbundel It looks really nice :) -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc fails
On 16/03/2013 6:27 PM, David Nalesnik wrote: /usr/bin/python -tt /home/david/lilypond-git/scripts/build/create-weblinks-itexi.py out-www/weblinks.itexi make[3]: *** No rule to make target `/home/david/lilypond-git/Documentation/cs/web/news-front.itexi', needed by `out-www/web.texi'. Stop. Try removing Documentation/cs/out-www/web.dep and running `make doc' again. If it succeeds but fails at the next language, repeat for each language. Alternatively, if all that fails, try `make doc-clean' and running `make doc' again. Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: build: missing explicit dependency?
On Thu, Mar 14, 2013 at 5:39 AM, Francisco Vila paconet@gmail.com wrote: 2013/3/12 Julien Rioux jri...@lyx.org: OK I see, so testing for the binaries is not enough. We`ll need to find out what else is required and add a test for it. Does anybody know? If you or anyone else do uninstall texlive-metapost and provide a log from a failed make, I think that would be useful. I uninstalled texlive-metapost and removed the mf/out directory. Then issued ./autogen.sh and obtained the green light to run 'make'. It stopped with these last lines: Output written on parmesan-noteheads26.600gf (101 characters, 29364 bytes). Transcript written on parmesan-noteheads26.log. mv parmesan-noteheads26.log parmesan-noteheads26.tfm ./out rm -f parmesan-noteheads26.*gf parmesan-noteheads26.*pk ~/source/lilypond/scripts/build/out/mf-to-table \ --global-lisp=./out/feta11.otf-gtable \ --lisp=./out/feta11.lisp \ --outdir=./out \ --enc ./out/feta11.enc \ out/feta11.log cd ./out \ touch mf2pt1.mem \ mpost -progname=mpost -ini ~/source/lilypond/mf/mf2pt1.mp \\dump This is MetaPost, version 1.504 (kpathsea version 6.1.0) (~/source/lilypond/mf/mf2pt1.mp ! I can't open file `mfplain'. l.27 input mfplain ; Please type another input file name: That's it. I searched for mfplain and found that texlive-metapost provides /usr/share/texlive/texmf-dist/metapost/base/mfplain.mp and /usr/share/texlive/texmf-dist/metapost/config/mfplain.ini So I installed the package and compiling could continue. Thanks -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com This commit: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commit;h=8d2268dbc8bcd94e14105196a8f8ac0ed8fceb34 adds the file mp/mf2pt1.mp to our git repository. This file contains input mfplain so it relies on mfplain.mp being available. We can search for mfplain.mp during ./configure using kpsewhich, but I wonder if we should instead just distribute this file in our git repository along with mf2pt1.mp? c.c.ing Werner who added mf2pt1.mp initially. -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: build: missing explicit dependency?
On 02/03/2013 11:54 AM, Francisco Vila wrote: Hello. When trying to build lilypond, I had to install the texlive-metapost package which the autogen.sh did not ask for. Is this a flaw of the config process? Actually, ./configure is checking for both mf and mpost. Do you still have a config.log around from the failing build by any chance? -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: build: missing explicit dependency?
On Tue, Mar 12, 2013 at 2:05 PM, Francisco Vila paconet@gmail.com wrote: 2013/3/12 Julien Rioux jri...@lyx.org: On 02/03/2013 11:54 AM, Francisco Vila wrote: Hello. When trying to build lilypond, I had to install the texlive-metapost package which the autogen.sh did not ask for. Is this a flaw of the config process? Actually, ./configure is checking for both mf and mpost. Do you still have a config.log around from the failing build by any chance? No. I have one that contains configure:7216: found /usr/bin/mpost configure:7227: result: mpost ... configure:7067: found /usr/bin/mf-nowin configure:7078: result: mf-nowin but mpost and mf-nowin are provided by the texlive-binaries package in my distro. I had to install texlive-metapost in addition. I could try uninstalling it and see if it fails. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com OK I see, so testing for the binaries is not enough. We`ll need to find out what else is required and add a test for it. Does anybody know? If you or anyone else do uninstall texlive-metapost and provide a log from a failed make, I think that would be useful. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: build: missing explicit dependency?
On 05/03/2013 11:07 AM, Francisco Vila wrote: 2013/3/3 James pkx1...@gmail.com: On 2 March 2013 16:54, Francisco Vila paconet@gmail.com wrote: Hello. When trying to build lilypond, I had to install the texlive-metapost package which the autogen.sh did not ask for. Is this a flaw of the config process? Well when I follow the NR to install the software to compile LP the builddep-lilypond seems to contain this NR? you mean CG http://lilypond.org/doc/v2.17/Documentation/contributor/requirements-for-compiling-lilypond What is the builddep-lilypond and why do we link to ubuntu? Sorry, I don't understand. https://launchpad.net/ubuntu/precise/+source/lilypond I am not sure what Linux Dist you are using but did you follow the NR or are you getting the parts in a different way. I tried not to install any package that weren't required and therefore I installed only what config took as enough to start compiling. After issuing 'make' it did fail for a missing package not listed explicitly by autogen.sh Yes, CG does lists metapost. But this peckage was not auto-installed as a dependency from other previous packages. I agree that this looks like something that the configure script should have caught. Thanks for reporting it, we should open an issue for it. -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Alternative pixel-based regtest checker
On 01/03/2013 2:15 PM, Phil Holmes wrote: 4 files attached. To try this out: create a new directory and place NoTagline.ly in it. Create a subdirectory called input and put some regtest files in there. Run MakeOldPix.sh. Make a change to lilypond. Run MakeNewPix.sh. Run ComparePix.sh. Om my tests there were some false alarms, but it seems a fairly simple way to make an alternative regtest checker. There's lots of improvements that could be made: parallelism, using something other than diff, but it basically works. Thoughts? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel I haven't tested your code, I am sure it is useful, I just have one thing to note: Are you aware of the --threshold command-line switch for script/build/output-distance.py? I wonder if setting it to a lower default value would not reveal the missing regtest changes that you are presumably looking for. -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: CG: explicitly detail the correct values for git cl config (issue 7096052)
At this point, the git-cl used by the project has been sufficiently geared towards lilypond development that I somewhat doubt anybody is using it for work outside of lilypond. It might not make sense at all for our git-cl to keep asking these superfluous questions; should they be remove entirely? https://codereview.appspot.com/7096052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: DOC: Update CG 8.7 Patch Handling (issue 7101048)
Reitveld - Rietveld https://codereview.appspot.com/7101048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix KeyError in website_post.py from Issue 847 (issue 7021043)
LGTM https://codereview.appspot.com/7021043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update contributors. (issue 6689045)
I missed that Bertrand Bordage, Joe Neeman, and Carl D. Sorensen are listed both under developers and contributors. According to the policy they should be removed from contributors. Also Colin Hall is listed under developers so probably should not be added under contributors: bug squad like I did. The list of main developers looks rather long. Are there any current developers to move to previous developers (e.g. they haven't been around for a while)? Cheers, Julien http://codereview.appspot.com/6689045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update contributors. (issue 6689045)
On Fri, Oct 19, 2012 at 8:47 AM, Janek Warchoł janek.lilyp...@gmail.com wrote: On Fri, Oct 19, 2012 at 10:36 AM, julien.ri...@gmail.com wrote: I missed that Bertrand Bordage, Joe Neeman, and Carl D. Sorensen are listed both under developers and contributors. According to the policy they should be removed from contributors. Also Colin Hall is listed under developers so probably should not be added under contributors: bug squad like I did. The list of main developers looks rather long. Are there any current developers to move to previous developers (e.g. they haven't been around for a while)? depends on what you mean. I don't remember any commits from Jonathan Kulp, Mark Polesky, Carl Sorensen and Neil Puttock in past couple of months, but all of them send an email or two from time to time. Janek Seems fine then. I meant more like if there was inactivity for years. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: problem uploading a patch
On 10/17/2012 02:55 PM, David Nalesnik wrote: Julien, On Wed, Oct 17, 2012 at 1:33 AM, Julien Rioux jri...@physics.utoronto.ca wrote: On 16/10/2012 4:36 PM, David Nalesnik wrote: david@david-desktop ~/lilypond-git (dev/measure_counter)$ git cl issue 2445 Issue number: 2445 (http://codereview.appspot.com/2445) This should be the issue number from the Rietveld page, not the one from google code page. OK, I see. Thanks! I figured that I'd need to create the Rietveld issue first, which I attempted to do using the issue creation form. Unfortunately, I can't get past the requirement for a url or uploaded file. What should I do here? -David $ git cl issue 0 to reset (remove any association to a Rietveld issue) $ git cl upload origin/master to upload (given that the branch is no longer associated to a Rietveld issue, it will create a new Rietveld issue) Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Update contributors. (issue 6689045)
On Mon, Oct 15, 2012 at 5:18 PM, gra...@percival-music.ca wrote: Sorry, there's a bit of confusion here. The past policy was: Thanks, I've updated the file to clarify the policy and made sure that I do not move contributors from past to current but simply add them to current. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Translations for create-weblinks-itexi.py (issue 6681045)
On Mon, Oct 15, 2012 at 7:40 AM, janek.lilyp...@gmail.com wrote: this looks strange: when i go to side-by-side diffs, i don't see any changes, just error: old chunk mismatch. I don't know what caused that, but you can rely on the raw patch set. Since this patch only adds lines and does not remove any lines, the reviewing shouldn't suffer much from missing side-by-side view. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly (issue 2670) (issue 6610058)
On Mon, Oct 8, 2012 at 4:08 PM, gra...@percival-music.ca wrote: The changelog says Don't update \version when no rule is applied. That's what the existing -d --diff-version-update command does. If this is intended to be the default behaviour now, then the command-line option should be removed. No, -d does not become the default; the behavior of convert-ly is unchanged when rules are being applied, and -d is still used in the same way. The change concerns itself only with the case that no rule applies, because the version of the file is already up-to-date. In this case, it used to be that the version in the file would be set to version of the last rule, which would sometimes mean that the version of the file upon output is lower than the version at input. This is what we avoid in this patch. Please consult http://code.google.com/p/lilypond/issues/detail?id=2670 and references therein. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [talk] why it'd be great to have web interface for submittingsimple doc patches
On 07/10/2012 5:33 AM, Phil Holmes wrote: - Original Message - From: Joseph Rushton Wakeling joseph.wakel...@webdrake.net To: Phil Holmes m...@philholmes.net Cc: James pkx1...@gmail.com; lilypond-devel@gnu.org Sent: Saturday, October 06, 2012 5:26 PM Subject: Re: [talk] why it'd be great to have web interface for submittingsimple doc patches On 10/06/2012 05:46 PM, Phil Holmes wrote: As you say, compile-edit-compile cycles are shorter than the full build, but can occasionally not reveal errors, so for a proper test it's always better to nuke the build directory and rebuild from scratch. Out of curiosity, what kind of errors? I imagine stuff involving cross-references, the index, etc.? It's more that there are a variety of outputs generated from the doc source - pdf, split html, large html, info, etc. - to be sure that the source is OK you need to be certain all have been generated and therefore checked, and the simplest way of ensuring that is from a clean build. -- Phil Holmes It should be possible to avoid make clean. There will be a need for make doc-clean when moving or removing an included file. Other cases should be considered as bugs. If you witness that something doesn't get regenerated after you modified a file, please file it as a bug. -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: convert-ly (issue 2670) (issue 6610058)
On Sat, Oct 6, 2012 at 1:06 AM, lemzw...@googlemail.com wrote: Are you going to report the number of errors using the `errors' variable? In case this is true, I would consider this a bad idea, since you abuse the functionality of the exit status. How large can `errors' become? The value returned by `exit' must be in the range 0-255 (with 0 meaning `no error'). http://codereview.appspot.com/**6610058/http://codereview.appspot.com/6610058/ I thought it would be interesting to track the number of errors, yes, but you are absolutely right. I`ll change it to return 0 (success) or 1 (failure). Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
convert-ly (issue 2670) (issue 6610058)
Reviewers: ,
Message:
For review:
Description:
convert-ly:
- Exit with error status when errors occur.
- Use unicode strings for file names printing.
- Don't update \version when no rule is applied.
This fixes issue 2670.
Please review this at http://codereview.appspot.com/6610058/
Affected files:
M scripts/convert-ly.py
Index: scripts/convert-ly.py
diff --git a/scripts/convert-ly.py b/scripts/convert-ly.py
index
2772acc7382c144590cb73ca2da6c3db58603059..c755eb71c3a10a2a4556c2dd16b433dc9f42a386
100644
--- a/scripts/convert-ly.py
+++ b/scripts/convert-ly.py
@@ -185,10 +185,9 @@ string.
ly.progress (_ (Applying conversion: ), newline = False)
-last_conversion = ()
+last_conversion = None
+errors = 0
try:
-if not conv_list:
-last_conversion = to_version
for x in conv_list:
if x != conv_list[-1]:
ly.progress (tup_to_str (x[0]), newline = False)
@@ -202,8 +201,9 @@ string.
ly.error (_ (Error while converting)
+ '\n'
+ _ (Stopping at last successful rule))
+errors += 1
-return (last_conversion, str)
+return (last_conversion, str, errors)
@@ -228,7 +228,7 @@ class InvalidVersion (Exception):
self.version = version
def do_one_file (infile_name):
-ly.progress (_ (Processing `%s\'... ) % infile_name, True)
+ly.progress (_ (uProcessing `%s\'... ) % infile_name, True)
if infile_name:
infile = open (infile_name, 'r')
@@ -256,12 +256,12 @@ def do_one_file (infile_name):
raise InvalidVersion (..join ([str(n) for n in from_version]))
-(last, result) = do_conversion (input, from_version, to_version)
+(last, result, errors) = do_conversion (input, from_version,
to_version)
+if global_options.force_current_version and \
+(last is None or last == to_version):
+last = str_to_tuple (program_version)
if last:
-if global_options.force_current_version and last == to_version:
-last = str_to_tuple (program_version)
-
if global_options.diff_version_update:
if result == input:
# check the y in x.y.z (minor version number)
@@ -281,23 +281,24 @@ def do_one_file (infile_name):
elif not global_options.skip_version_add:
result = newversion + '\n' + result
-ly.progress ('\n')
-
-if global_options.edit:
-try:
-os.remove(infile_name + '~')
-except:
-pass
-os.rename (infile_name, infile_name + '~')
-outfile = open (infile_name, 'w')
-else:
-outfile = sys.stdout
-
+ly.progress ('\n')
-outfile.write (result)
+if global_options.edit and result != input:
+try:
+os.remove(infile_name + '~')
+except:
+pass
+os.rename (infile_name, infile_name + '~')
+outfile = open (infile_name, 'w')
+else:
+outfile = sys.stdout
+outfile.write (result)
+
sys.stderr.flush ()
+return errors
+
def do_options ():
opt_parser = get_option_parser()
(options, args) = opt_parser.parse_args ()
@@ -331,25 +332,29 @@ def main ():
identify ()
+errors = 0
for f in files:
if f == '-':
-f = ''
-elif not os.path.isfile (f):
-ly.error (_ (%s: Unable to open file) % f)
-if len (files) == 1:
-sys.exit (1)
+continue
+f = f.decode(sys.stdin.encoding or utf-8)
+if not os.path.isfile (f):
+ly.error (_ (u%s: Unable to open file) % f)
+errors += 1
continue
try:
-do_one_file (f)
+errors += do_one_file (f)
except UnknownVersion:
-ly.error (_ (%s: Unable to determine version. Skipping) % f)
+ly.error (_ (u%s: Unable to determine version. Skipping) %
f)
+errors += 1
except InvalidVersion:
# Compat code for 2.x and 3.0 syntax (except .. as v doesn't
# work in python 2.4!):
t, v, b = sys.exc_info ()
-ly.error (_ (%s: Invalid version string `%s' \n
+ly.error (_ (u%s: Invalid version string `%s' \n
Valid version strings consist of three numbers,
separated by dots, e.g. `2.8.12') % (f,
v.version) )
+errors += 1
+sys.exit(errors)
main ()
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: treat iffalse sections in latex as block comments (issue 6584073)
Try to add a regression test example with a valid lilypond block inbetween two multiline comments. http://codereview.appspot.com/6584073/diff/1/python/book_latex.py File python/book_latex.py (right): http://codereview.appspot.com/6584073/diff/1/python/book_latex.py#newcode88 python/book_latex.py:88: \\iffalse.*\\fi))''', .* should be replaced by the non-greedy .*? http://codereview.appspot.com/6584073/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy switches for forcing make doc don't seem to work
On 20/08/2012 8:53 AM, James wrote:
John,
On 20 August 2012 13:09, John Mandereau john.mander...@gmail.com wrote:
Hi James,
Il giorno lun, 20/08/2012 alle 10.40 +0100, James ha scritto:
I am not able to work out how to force patchy during a test-patches.py
to also make doc as well as the test and test-baseline.
I don't have access to my machine I run patchy on at the moment - it
is at home and I am at work - but there is an entry in one of the
'conf' files that allows me to set the option to make doc 'TRUE'.
Are you sure there is such an entry? I have looked at the configuration
files
(patches/{lilypond-patchy-config-DEFAULT,compile_lilypond_test/pachy_config.py})
git history, and I haven't found anything that kinda matched.
https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test/__init__.py
Line #37
On line #431, change quick_make=True to quick_make=False and you will be
doing a `make doc' (in addition to `make check' and everything).
A command-line switch would be much better, but for the time being this
is something you could do.
Cheers,
Julien
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make test
On 08/08/2012 4:59 AM, Phil Holmes wrote: I've been looking at how the regression test comparison works. The first thing I find is that we have 2 effectively duplicate, but different, pages on running regtest comparisons: http://lilypond.org/doc/v2.15/Documentation/contributor/verify-regression-tests http://lilypond.org/doc/v2.15/Documentation/contributor/regtest-comparison I think the latter is probably more accurate. I think it would be best to delete one and point to the other? I've also been benchmarking. For example, I know that make CPU_COUNT=9 test is _much_ faster than make test, but the make -j9 test isn't worth doing - most of the time is spent building the single regtest document, which lilypond parallelises much better than make. I have had errors using -jX so am slightly suspicious of that option. I would like to add the best way to parallelise the test process to the CG. Currently the build system is set up so that all regtests in a given directory are processed by one instance of lilypond (called from lilypond-book). Since there is only one process, there really isn't anything that `make' could parallelize in this area. At the same time, there's nothing to fear in using -j9 to make test. I've also been looking at how output-distance works. Does anyone now understand what this actually does? From following the code, it looks to me like it doesn't actually compare images - it compares the .signature files, and if there's a difference over the threshold, it creates an image of the original and changed file, and then makes a ghost version of the change to overlay on the original. Does this seem correct. Worth documenting? -- Phil Holmes -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix for several musicxml2ly bugs. (issue 5697059)
Hi Patrick, A cleaned up version of this patch has been committed (and credited to you), so you may close this Rietveld issue. You will see the fix in version 2.15.41, the next development release. Cheers, Julien http://codereview.appspot.com/5697059/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: LSR updates and translations
On 25/06/2012 1:53 PM, John Mandereau wrote: Il giorno lun, 25/06/2012 alle 18.50 +0100, Phil Holmes ha scritto: And John M could no doubt help. It's a question of how much time they have to contribute. If what we want to achieve is well enough specified, then I can offer to go for it. Cheers, John I would be happy to help, too, though time is sparse. What I miss here is a concrete example of what is needed, as I couldn't quite figure out the actual problem at hand. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Treat accidentals parentheses as cautionary (issue 6310065)
Reviewers: MikeSol, Graham Percival,
Message:
On 2012/06/22 08:20:56, Graham Percival wrote:
LGTM, although I'd personally have prepended musicxml2ly: to the
beginning of
the patch subject line. That makes it much more obvious when skimming
the git
history (or just available patches to review).
I just did a git am using his patch, but I'll amend the commit before
pushing. Do we need some license statement from Rodolfo?
--
Julien
Description:
Treat accidentals parentheses as cautionary
Patch from Rodolfo Zitellini
Please review this at http://codereview.appspot.com/6310065/
Affected files:
M scripts/musicxml2ly.py
Index: scripts/musicxml2ly.py
diff --git a/scripts/musicxml2ly.py b/scripts/musicxml2ly.py
index
69125dc9db6cdccbb52d47c19296c6191974fa4e..cd76ebeca3e14d073aa7c24d6c0098c040d9c1c9
100644
--- a/scripts/musicxml2ly.py
+++ b/scripts/musicxml2ly.py
@@ -1784,8 +1784,12 @@ def musicxml_note_to_lily_main_event (n):
acc = n.get_maybe_exist_named_child ('accidental')
if acc:
-# let's not force accs everywhere.
-event.cautionary = acc.cautionary
+# AccidentalCautionary in lily has parentheses
+# so treat accidental explicitly in parentheses as cautionary
+if hasattr(acc, 'parentheses') and acc.parentheses == yes:
+event.cautionary = True
+else:
+event.cautionary = acc.cautionary
# TODO: Handle editorial accidentals
# TODO: Handle the level-display setting for displaying
brackets/parentheses
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add missing shebang line in MacOSX instructions. (issue 6300118)
Reviewers: Graham Percival,
Message:
On 2012/06/22 08:19:29, Graham Percival wrote:
I thought that bash doesn't need the shebang in some cases? at least,
I could
have sworn that I never added the shebang in this case?
As I understand it, problems ensue when you try to call that script from
python.
--
Julien
Description:
Add missing shebang line in MacOSX instructions.
Please review this at http://codereview.appspot.com/6300118/
Affected files:
M Documentation/web/download.itexi
Index: Documentation/web/download.itexi
diff --git a/Documentation/web/download.itexi
b/Documentation/web/download.itexi
index
55306b48d89798718b81951c45706e9343885d25..365ecedaa3595aac6da3db6860c35f72d1653778
100644
--- a/Documentation/web/download.itexi
+++ b/Documentation/web/download.itexi
@@ -358,6 +358,7 @@ Create a file called @command{lilypond} which contains
@divClass{h-scroll-auto}
@example
+#!/bin/bash
exec @var{DIR}/LilyPond.app/Contents/Resources/bin/lilypond $@@
@end example
@divEnd
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Website build crashing
On 26/04/2012 5:53 AM, m...@mikesolomon.org wrote: Hey all, My website build crashes with: mikesol@mikesol-laptop:~/lilypond-git$ sudo make LILYPOND_WEB_MEDIA_GIT=/home/mikesol/lilypond-extra website make --no-builtin-rules config_make=./config.make \ top-src-dir=/home/mikesol/lilypond-git \ -f /home/mikesol/lilypond-git/make/website.make \ website make[1]: Entering directory `/home/mikesol/lilypond-git' cp /home/mikesol/lilypond-git/Documentation/misc/out out-website/website/misc/out cp: omitting directory `/home/mikesol/lilypond-git/Documentation/misc/out' make[1]: *** [out-website/website/misc/out] Error 1 make[1]: Leaving directory `/home/mikesol/lilypond-git' make: *** [website] Error 2 It seems that the cp command is trying to copy the misc/out directory without adding the -r flag. Can someone confirm this problem before I open a tracker issue? Cheers, MS I confirm. Did you create an issue for it? -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes .tex files to get rid of warning (issue 5976055)
On Sun, Apr 1, 2012 at 2:32 PM, philehol...@googlemail.com wrote:
Reviewers: Julien Rioux, Graham Percival, dak,
Message:
Please review
Description:
These files used what appears to be a deprecated syntax to invoke
lilypond-book, resulting in these warnings:
lilypond-book.py: warning: deprecated ly-option used: 11pt=None
lilypond-book.py: warning: compatibility mode translation: staffsize=11
Applying these changes gets rid of those errors in make doc.
Please review this at http://codereview.appspot.com/5976055/
Affected files:
Documentation/usage/latex-lilypond-example.latex
M input/regression/lilypond-book/tex-comments.lytex
M input/regression/lilypond-book/tex-compatibility-mode.lytex
M input/regression/lilypond-book/tex-lilypond-inside-itemize.lytex
M input/regression/lilypond-book/tex-lilypond-inside-table.lytex
Index: input/regression/lilypond-book/tex-compatibility-mode.lytex
diff --git a/input/regression/lilypond-book/tex-compatibility-mode.lytex
b/input/regression/lilypond-book/tex-compatibility-mode.lytex
index
aab288e7b3504e235b72706b45e27688cade59ca..933b7ec4fd7d82fbcffd231baf0ded51d8cc2c0e
100644
--- a/input/regression/lilypond-book/tex-compatibility-mode.lytex
+++ b/input/regression/lilypond-book/tex-compatibility-mode.lytex
@@ -5,6 +5,6 @@
A snippet with a deprecated option, triggering compatibility mode:
-\lilypond[11pt,fragment]{c' e' g'}
+\lilypond[staffsize=11,fragment]{c' e' g'}
\end{document}
This change to tex-compatibility-mode.tex makes no sense. The whole
point of this file is to test that deprecated options are still
supported.
--
Julien
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: CG Update compile.itexi for doc build (issue 5967060)
LGTM http://codereview.appspot.com/5967060/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Changes .tex files to get rid of warning (issue 5976055)
On Mon, Apr 2, 2012 at 11:11 AM, Phil Holmes em...@philholmes.net wrote:
- Original Message - From: Julien Rioux julien.ri...@gmail.com
To: philehol...@googlemail.com; julien.ri...@gmail.com;
gra...@percival-music.ca; d...@gnu.org; lilypond-devel@gnu.org;
re...@codereview-hr.appspotmail.com
A snippet with a deprecated option, triggering compatibility mode:
-\lilypond[11pt,fragment]{c' e' g'}
+\lilypond[staffsize=11,fragment]{c' e' g'}
\end{document}
This change to tex-compatibility-mode.tex makes no sense. The whole
point of this file is to test that deprecated options are still
supported.
--
Julien
Excellent catch - thanks, Julien. I was in auto-correct mode. How do you
suggest we correct this? I doubt we want this warning displayed.
run-and-check?
--
Phil Holmes
Yes I think run-and-check is fine for this.
--
Julien
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volunteer for patchy new-patches
On 27/03/2012 1:48 PM, Marek Klein wrote: Hi, 2012/3/23 Graham Percivalgra...@percival-music.ca Well, you need to figure out why git fetch in your $LILYPOND_GIT repository fails. git fetch works now... I need som new patch for play with... Marek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel When there are no issues with a label of Patch=new, you can still test patches by specifying issue numbers on the command line like this: python test-patches.py 2216 without having to reset the said issue. -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: In-tree make check fails with lilypond-book include file regtest.
On 27/03/2012 9:37 AM, David Kastrup wrote: David Kastrupd...@gnu.org writes: commit ee70161485a2d2f347db3e29724a943c741ef524 Author: Julien Riouxjri...@physics.utoronto.ca Date: Wed Mar 21 09:13:55 2012 -0400 Regtests for lilypond-book include files located in subdir. causes the regtests to fail. Rerunning configure, make clean and make test does not help. Reverted for now. I locally reverted your revert and could make, make test and make doc from scratch in the src dir after the fixes that I committed today. Unless there is any objections I will push the revert of the revert to staging. -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: dist-check failure
On 26/03/2012 8:42 PM, Graham Percival wrote:
ge.ja.html
file from VC not distributed:
lilypond-2.15.35/Documentation/misc/browser-language.nl.html
file from VC not distributed:
lilypond-2.15.35/input/regression/lilypond-book/include/example.ly
file from VC not distributed:
lilypond-2.15.35/input/regression/lilypond-book/include/myvar.ily
rm -rf /tmp/tmpGQR4Q7
Traceback (most recent call last):
File test-lily/dist-check.py, line 137, inmodule
main ()
File test-lily/dist-check.py, line 132, in main
check_files (tarball, repo)
File test-lily/dist-check.py, line 117, in check_files
raise Exception ('dist error found')
Exception: dist error found
- Graham
Is it fixed now with master?
--
Julien
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volunteer for patchy new-patches
On 27/03/2012 2:58 PM, Marek Klein wrote: 2012/3/27 Jamespkx1...@gmail.com I reset one of mine on the countdown http://code.google.com/p/lilypond/issues/detail?id=2216 Try that. This is the output: Trying issue 2216 Found patch: (2216, '/home/marek/lilypond-patchy/issue5843060_6001.diff', 'AU: Document all options for lilypond -dhelp') Problem compiling master. Patchy cannot reliably continue. Traceback (most recent call last): File test-patches.py, line 16, inmodule main(issues_id) File test-patches.py, line 12, in main patchy.do_check(issues) File /home/marek/lilypond-patchy/projecthosting_patches.py, line 213, in do_check compile_lilypond_test.main(patches) File /home/marek/lilypond-patchy/compile_lilypond_test.py, line 289, in main raise err Exception: Failed runner: nice make test-baseline -j3 CPU_COUNT=3 See the log file log-None-nice-make-test-baseline--j3-CPU_COUNT=3.txt However, I cannot find the log file :( Marek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel On a default configuration this logfile would be in /tmp/lilypond-autobuild Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volunteer for patchy new-patches
On 27/03/2012 3:20 PM, Marek Klein wrote: 2012/3/27 Julien Riouxjri...@physics.utoronto.ca On 27/03/2012 2:58 PM, Marek Klein wrote: However, I cannot find the log file :( On a default configuration this logfile would be in /tmp/lilypond-autobuild Cheers, Julien Here it is: http://gregoriana.sk/data/log-None-nice-make-test-baseline--j3-CPU_COUNT=3.txt (The word Chyba means Error) Marek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel So it points to /tmp/lilypond-autobuild/build/out/lybook-testdb/snippet-names--7220266384705246370.log Is that file still around? -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Don't reload initialization files when processing multiple files (issue 5874044)
LGTM http://codereview.appspot.com/5874044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Corrected style of comments (issue 5862052)
Are the changes to .gitignore intentional? http://codereview.appspot.com/5862052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Set include path for --output option (issue 2423). (issue 5846075)
On Wed, Mar 21, 2012 at 9:37 AM, Julien Rioux julien.ri...@gmail.com wrote: On Wed, Mar 21, 2012 at 1:39 AM, joenee...@gmail.com wrote: http://codereview.appspot.com/5846075/diff/1/scripts/lilypond-book.py File scripts/lilypond-book.py (right): http://codereview.appspot.com/5846075/diff/1/scripts/lilypond-book.py#newcode639 scripts/lilypond-book.py:639: global_options.include_path.insert (0, inverse_relpath (original_dir, global_options.output_dir)) Wouldn't it be easier if you just added the absolute path to original_dir? It would be easier, but I think the proposed patch is a better implementation. Using absolute paths makes the document less portable and prone to errors caused by any weird characters that a user might have in the names of parent directories. Absolute paths also didn't play well with lilypond on Windows (see http://code.google.com/p/lilypond/issues/detail?id=2209 ). While I didn't test the suggested patch on Windows yet, I will do so very soon. Regards, Julien http://codereview.appspot.com/5846075/ So after some testing, this looks good with python on windows, too. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Set include path for --output option (issue 2423). (issue 5846075)
On Wed, Mar 21, 2012 at 1:39 AM, joenee...@gmail.com wrote: http://codereview.appspot.com/5846075/diff/1/scripts/lilypond-book.py File scripts/lilypond-book.py (right): http://codereview.appspot.com/5846075/diff/1/scripts/lilypond-book.py#newcode639 scripts/lilypond-book.py:639: global_options.include_path.insert (0, inverse_relpath (original_dir, global_options.output_dir)) Wouldn't it be easier if you just added the absolute path to original_dir? It would be easier, but I think the proposed patch is a better implementation. Using absolute paths makes the document less portable and prone to errors caused by any weird characters that a user might have in the names of parent directories. Absolute paths also didn't play well with lilypond on Windows (see http://code.google.com/p/lilypond/issues/detail?id=2209 ). While I didn't test the suggested patch on Windows yet, I will do so very soon. Regards, Julien http://codereview.appspot.com/5846075/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A new home for browser-language (issue 2412). (issue 5870043)
On Wed, Mar 21, 2012 at 4:33 PM, gra...@percival-music.ca wrote: http://codereview.appspot.com/5870043/diff/1/python/auxiliar/postprocess_html.py File python/auxiliar/postprocess_html.py (right): http://codereview.appspot.com/5870043/diff/1/python/auxiliar/postprocess_html.py#newcode71 python/auxiliar/postprocess_html.py:71: browser_language_url = /misc/browser-language please change to /website/misc/browser-language. I'm not 100% certain it's safe to have a /misc/ so let's avoid that potential problem for now. http://codereview.appspot.com/5870043/ Sure I'll change it. Does this also apply to the other patch on countdown i.e. http://codereview.appspot.com/5843069/diff/17/Documentation/common-macros.itexi ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tracks old announcements, news and changelogs. (issue 5843069)
On Wed, Mar 21, 2012 at 5:16 PM, gra...@percival-music.ca wrote:
http://codereview.appspot.com/5843069/diff/17/Documentation/common-macros.itexi
File Documentation/common-macros.itexi (right):
http://codereview.appspot.com/5843069/diff/17/Documentation/common-macros.itexi#newcode185
Documentation/common-macros.itexi:185:
@uref{http://www.lilypond.org/misc/\MISC-FILE\,\MISC-TEXT\}
sorry, please change this to http://www.lilypond.org/website/misc/
http://codereview.appspot.com/5843069/
Done. I'm running patch-new patchy on this.
Julien
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A new home for browser-language (issue 2412). (issue 5870043)
On Wed, Mar 21, 2012 at 4:42 PM, Julien Rioux julien.ri...@gmail.com wrote: On Wed, Mar 21, 2012 at 4:33 PM, gra...@percival-music.ca wrote: http://codereview.appspot.com/5870043/diff/1/python/auxiliar/postprocess_html.py File python/auxiliar/postprocess_html.py (right): http://codereview.appspot.com/5870043/diff/1/python/auxiliar/postprocess_html.py#newcode71 python/auxiliar/postprocess_html.py:71: browser_language_url = /misc/browser-language please change to /website/misc/browser-language. I'm not 100% certain it's safe to have a /misc/ so let's avoid that potential problem for now. http://codereview.appspot.com/5870043/ Sure I'll change it. Does this also apply to the other patch on countdown i.e. http://codereview.appspot.com/5843069/diff/17/Documentation/common-macros.itexi Done. I'm running patch-new patchy on this. Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Tracks old announcements, news and changelogs. (issue 5843069)
On Tue, Mar 20, 2012 at 2:07 PM, gra...@percival-music.ca wrote: LGTM http://codereview.appspot.com/5843069/ Thanks for having a look. By the way, it looks like http://lilypond.org/website just replicates http://lilypong.org at a deeper level -- any reason why this is so? Is that from before the switch to the new website? Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volunteer for patchy new-patches
On 20/03/2012 4:26 PM, Marek Klein wrote: Hi, 2012/3/16 Graham Percivalgra...@percival-music.ca On Fri, Mar 16, 2012 at 09:52:52PM +0100, Marek Klein wrote: I can do it, I think (almost every day). Great! Here's the link to get started: http://lilypond.org/doc/v2.15/Documentation/contributor/patchy ... although apparently that doesn't include a link to the actual code. huh. https://github.com/gperciva/lilypond-extra - Graham what are the next steps? Should I try to run python lilypond-patchy-staging.py ? Marek python test-patches.py -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: What's with the build directories?
Graham Percival graham at percival-music.ca writes: On Mon, Mar 19, 2012 at 01:24:54PM +0100, David Kastrup wrote: I find that in my patchy runs, I get directories /tmp/lilypond-autobuild (my configured build directory) and a hierarchy of build directories under it, possibly one per tested patch (?). nope, nothing to do with Patchy. ls /tmp/lilypond-autobuild/build/build/build/build/ GNUmakefile local.make That's normal. People were asking why we have nested build dirs at least two years ago. *shrug* Patches appreciated? I'm not eager to poke the build system with a sharp stick. So I did a quick search but I'm probably not touching it either. Lines 421, 422 of stepmake/aclocal.m4: for mf in `cd $srcdir ; find . -maxdepth $d -mindepth $d -name GNUmakefile`; do mkdir -p $(dirname $mf) recursively search for files named GNUmakefile and create a corresponding directory in the build dir. The build dir itself contains a GNUmakefile. This happens at each configure run (which Patchy happens to do at every patch). Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Sets lilypond-id message to type progress (issue 5848056)
On Sun, Mar 18, 2012 at 1:49 PM, gra...@percival-music.ca wrote:
http://codereview.appspot.com/5848056/diff/1/scripts/lilypond-book.py
File scripts/lilypond-book.py (right):
http://codereview.appspot.com/5848056/diff/1/scripts/lilypond-book.py#newcode104
scripts/lilypond-book.py:104: progress(_ ('%s (GNU LilyPond) %s' %
(ly.program_name, ly.program_version)))
We don't need the _ (), we don't translate that string.
Julien
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Copy pdf docs to new website folder (issue 5507046)
On 2012/01/03 20:36:48, Graham Percival wrote: On Tue, Jan 03, 2012 at 06:31:54PM +, mailto:hashas...@gmail.com wrote: Sorry, didn't understand what you mean by add issue 2166 to track this It's not relevant unless you're going to be making other patches. If you are, read the summary for experienced developers again in more detail. The git-cl step wasn't done properly. Anything I can do to help this to get live? Wait a day or two. It's on the countdown right now. See the summary for experienced developers if you don't know what that means. Cheers, - Graham This rietveld issue can be closed. http://codereview.appspot.com/5507046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Hiding old website /web/install page (issue 5500069)
this rietveld issue can be closed. http://codereview.appspot.com/5500069/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FW: [LilyPond] Your organization application has been rejected.
On 16/03/2012 4:54 PM, Graham Percival wrote: On Fri, Mar 16, 2012 at 7:37 PM, Graham Percival gra...@percival-music.ca wrote: It might be good to wait a week to see what projects were accepted, http://www.google-melange.com/gsoc/accepted_orgs/google/gsoc2012 ? Somebody on another venue pointed out that it'll take a few hours or days for the complete list to show up; at that time, it was only showing the first 30% of accepted projects. It's only showing projects that have filled up their landing page on google-melange.com There are a few organisations interesting for lilypond hackers: inkscape (to learn about svg), closure (to learn a scheme-like language), buildbot (could be helpful but we already have the gran unified builder). -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FW: [LilyPond] Your organization application has been rejected.
On 16/03/2012 4:45 PM, Janek Warchoł wrote: On Fri, Mar 16, 2012 at 6:53 PM, Carl Sorensenc_soren...@byu.edu wrote: On 3/16/12 11:44 AM, no-re...@google-melange.appspotmail.com no-re...@google-melange.appspotmail.com wrote: Thank you for submitting LilyPond organization application to Google Summer of Code 2012. Unfortunately, we were unable to accept your organization's application at this time. We received many more applications for the program than we are able to accommodate, and we would encourage you to reapply for future instances of the program. Best regards, Google Open Source Programs As you can see, we did not qualify for GSOC this year. No!! :( :( :( That's all they wrote? No feedback on our application anywhere? There should be a possibility to email/chat with them about the application process and how they come to this decision. This would be the best indication for next year. -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: volunteer for patchy new-patches
On 16/03/2012 4:55 PM, Graham Percival wrote: On Fri, Mar 16, 2012 at 09:52:52PM +0100, Marek Klein wrote: I can do it, I think (almost every day). Great! Here's the link to get started: http://lilypond.org/doc/v2.15/Documentation/contributor/patchy ... although apparently that doesn't include a link to the actual code. huh. https://github.com/gperciva/lilypond-extra - Graham No? http://lilypond.org/doc/v2.15/Documentation/contributor/patchy#Installing-patchy -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: FW: [LilyPond] Your organization application has been rejected.
On 16/03/2012 5:16 PM, Julien Rioux wrote: There are a few organisations interesting for lilypond hackers: inkscape (to learn about svg), closure (to learn a scheme-like language), buildbot (could be helpful but we already have the gran unified builder). libreoffice (improve the lilypond plugin), wikimedia (lilypond plugin again) -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Various updates to reduce make doc output (issue 5727055)
On Wed, Mar 14, 2012 at 9:56 AM, Phil Holmes em...@philholmes.net wrote: - Original Message - From: Julien Rioux julien.ri...@gmail.com To: Phil Holmes em...@philholmes.net It seems just not worth it. We _never_ want to check warnings as part of make doc. That's what regression tests are for. -- Phil Holmes I disagree, make -s doc is useful to identify warning messages that need fixing, and the log files are also useful for this. I think that the progress messages are what you should focus on silencing. The warning messages should be either fixed at the source or left in place so that someone eventually decides to fix them at the source. In this particular case, it might be that nobody will ever work to improve midi2ly, but that's not for us to say. Regards, Julien Sorry - I expressed myself badly. I meant that we shouldn't use make doc to check that warnings that we expect to appear do, in fact, continue to appear. We should use make test to check that the correct warnings continue to be output. I agree 100% that make doc _should_ make it easy to find new warnings we were unaware of. The problem with this one is that Lilypond (like Sibelius...) only provides 4 voices to allow notes to avoid colliding on a stave. I haven't delved deeply into midi2ly, but my assumption is that it maps midi channels on a single stave to different voices. The offending midi file has more that 4 channels on a stave and therefore the mapping to 4 voices is never going to work properly - and so midi2ly warns the user. But we don't want to continue to see those warnings on the screen, hence the suppression with -q. I can't see why an interactive user would use -q, so it won't give them a problem. I also don't believe that having another logfile solely to contain the message warning: found more than 5 voices on a staff, expect bad output makes much sense. Hence the way I went. -- Phil Holmes I'm fine with either 1) Leave the warning there (it's only one line of `make doc' output), or 2) Document in `midi2ly --help' that --quiet also silences warning messages. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Various updates to reduce make doc output (issue 5727055)
On Mon, Mar 12, 2012 at 6:26 PM, Phil Holmes em...@philholmes.net wrote: - Original Message - From: Graham Percival gra...@percival-music.ca To: Phil Holmes m...@philholmes.net Cc: philehol...@googlemail.com; d...@gnu.org; julien.ri...@gmail.com; lilypond-devel@gnu.org; re...@codereview-hr.appspotmail.com Sent: Monday, March 12, 2012 7:27 PM Subject: Re: Various updates to reduce make doc output (issue 5727055) On Mon, Mar 12, 2012 at 06:31:35PM -, Phil Holmes wrote: - Original Message - From: julien.ri...@gmail.com To: philehol...@googlemail.com; d...@gnu.org; gra...@percival-music.ca; m...@philholmes.net Cc: lilypond-devel@gnu.org; re...@codereview-hr.appspotmail.com Sent: Monday, March 12, 2012 6:18 PM Subject: Re: Various updates to reduce make doc output (issue 5727055) --quiet shouldn't suppress warning messages, everything else looks good. The problem with this warning message is that, as part of build, you can't fix it - if you want to test converting midi with more than 5 voices to lilypond, you'll get a message on screen, which is not what's wanted. Can't you redirect the midi2ly call to a log file? If a test is deliberately checking that a midi file with more than 5 voices should produce a warning, then we _want_ that warning saved to a logfile so we can check that the warning doesn't go away. Conversely, if we don't want that warning, then it's good to save it in a logfile so that future programmers can see the problem easily. - Graham It seems just not worth it. We _never_ want to check warnings as part of make doc. That's what regression tests are for. -- Phil Holmes I disagree, make -s doc is useful to identify warning messages that need fixing, and the log files are also useful for this. I think that the progress messages are what you should focus on silencing. The warning messages should be either fixed at the source or left in place so that someone eventually decides to fix them at the source. In this particular case, it might be that nobody will ever work to improve midi2ly, but that's not for us to say. Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Update roadmap, make and make doc info. (issue 5811043)
Reviewers: phileholmes_googlemail.com,
Message:
Please review.
Description:
Update roadmap, make and make doc info.
CG: Review info about the build system.
CG: Update info about make doc.
Update ROADMAP.
Please review this at http://codereview.appspot.com/5811043/
Affected files:
M Documentation/contributor/build-notes.itexi
M Documentation/included/compile.itexi
M ROADMAP
Index: Documentation/contributor/build-notes.itexi
diff --git a/Documentation/contributor/build-notes.itexi
b/Documentation/contributor/build-notes.itexi
index
bf779982290e370c48f89f3c5ecb92731b12ef02..a1e258cc91a369eb8b65d06c70a8e2efe411f3d6
100644
--- a/Documentation/contributor/build-notes.itexi
+++ b/Documentation/contributor/build-notes.itexi
@@ -117,9 +117,11 @@ include $(configure-srcdir)/GNUmakefile.in
The variable @code{depth} is used throughout the make system to
track how far down the directory structure the make is. The first
-include sets lots of variables but doesn't do anything. The
-second runs the file @file{GNUmakefile.in} from the top level
-source directory.
+include sets lots of variables but doesn't do anything. Default
+values for these variables are automatically detected at the
+./configure step, which creates the file @file{config.make}.
+The second include runs the file @file{GNUmakefile.in} from
+the top level source directory.
This sets another load of variables, and then includes (i.e.
immediately runs) @file{stepmake.make} from the @file{make}
@@ -957,6 +959,7 @@ described to some extent at
The file @file{lily-bib.bst} also has fairly extensive commenting.
+
@node Website build
@section Website build
Index: Documentation/included/compile.itexi
diff --git a/Documentation/included/compile.itexi
b/Documentation/included/compile.itexi
index
f4ed097da593411c2e20e41b1193735345a83616..c3aa45de1cffeaaae70ba9c589b04c9e68eec87c
100644
--- a/Documentation/included/compile.itexi
+++ b/Documentation/included/compile.itexi
@@ -605,7 +605,6 @@ Edit/compile cycle:
make [-j@var{X}] @emph{## needed if editing outside}
@emph{## Documentation/, but useful anyway}
@emph{## for finding Texinfo errors.}
-touch Documentation/*te?? @emph{## bug workaround}
make [-j@var{X} CPU_COUNT=@var{X}] doc @emph{## usually faster than
initial build.}
@end example
@@ -655,6 +654,17 @@ on their own with:
make LANGS='' doc
@end example
+@noindent Similarly, it is possible to compile a subset of the
+translated documentation by specifying their language codes on the
+command line. For example, the French and German translations are
+compiled with:
+
+@example
+make LANGS='de fr' doc
+@end example
+
+@noindent Note that this will also compile the English version.
+
Compilation of documentation in Info format with images can be
done separately by issuing:
@@ -705,6 +715,18 @@ However, this will rebuild all of the manuals
indiscriminately---it is more efficient to @command{touch} only
the affected files.
+@noindent
+Another typical issue when switching branches between master and
+lilypond/translation is the appearance/disappearance of translated
+versions of some manuals. If you see such a warning from make:
+
+@example
+No rule to make target `X', needed by `Y'
+@end example
+
+@noindent
+Your best bet is to delete the file Y.dep and to try again.
+
@node Building a single document
@unnumberedsubsubsec Building a single document
It's possible to build a single document. For example, to rebuild
Index: ROADMAP
diff --git a/ROADMAP b/ROADMAP
index
8b66091810a62b4c49cdc1ce0cfbeff5e877be81..99ad6b7fb6afe707b9079195a50a8a4f1fbc0f0a
100644
--- a/ROADMAP
+++ b/ROADMAP
@@ -26,7 +26,6 @@ LilyPond's source files.
| |-- notation/Notation Reference
| |-- usage/ Usage
| |-- web/ The website
-| | `-- ly-examples/ .ly files for the Examples page
| |
| |
| | TRANSLATED MANUALS:
@@ -36,6 +35,7 @@ LilyPond's source files.
| | * individual chapters for each manual
| | 2) a texidocs/ directory for snippet translations
| |
+| |-- cs/ Czech
| |-- de/ German
| |-- es/ Spanish
| |-- fr/ French
@@ -43,6 +43,7 @@ LilyPond's source files.
| |-- it/ Italian
| |-- ja/ Japanese
| |-- nl/ Dutch
+| |-- zh/ Chinese
| |
| |
| | MISCELLANEOUS DOC STUFF:
@@ -50,6 +51,7 @@ LilyPond's source files.
| |-- css/ CSS files for HTML docs
| |-- included/.ly files used in the manuals
| |-- logo/Web logo and note icon
+| |-- ly-examples/ .ly files for the Examples webpage
| |-- misc/Old announcements, ChangeLogs and NEWS
| |-- pictures/Images used (eps/jpg/png/svg)
| | `-- pdf/ (pdf)
@@ -95,6 +97,8 @@ LilyPond's source files.
|-- input/
| `--
