]> git.donarmstrong.com Git - lilypond.git/blobdiff - Documentation/contributor/lsr-work.itexi
Doc-fr: NR-1.5.2 merging rests
[lilypond.git] / Documentation / contributor / lsr-work.itexi
index c4dad5c28f1fcef58173e1f8f8d832ddf90842e2..9f4c6dcdfe65957bc8bb4c128be0fc23c656b383 100644 (file)
@@ -17,7 +17,7 @@
 @section Introduction to LSR
 
 The
-@uref{http://lsr.dsi.unimi.it/, LilyPond Snippet Repository (LSR)}
+@uref{http://lsr.di.unimi.it/, LilyPond Snippet Repository (LSR)}
 is a collection of lilypond examples.  A subset of these examples
 are automatically imported into the documentation, making it easy
 for users to contribute to the docs without learning Git and
@@ -31,7 +31,7 @@ Texinfo.
 
 When you create (or find!) a nice snippet, if it is supported by
 the LilyPond version running on the LSR, please add it to the LSR.
-Go to @uref{http://lsr.dsi.unimi.it/, LSR} and log in -- if you haven't
+Go to @uref{http://lsr.di.unimi.it/, LSR} and log in -- if you haven't
 already, create an account.  Follow the instructions on the website.
 These instructions also explain how to modify existing snippets.
 
@@ -108,7 +108,7 @@ filename.
 @section Approving snippets
 
 The main task of LSR editors is approving snippets.  To find a list of
-unapproved snippets, log into @uref{http://lsr.dsi.unimi.it/, LSR} and
+unapproved snippets, log into @uref{http://lsr.di.unimi.it/, LSR} and
 select @qq{No} from the dropdown menu to the right of the word
 @qq{Approved} at the bottom of the interface, then click
 @qq{Enable filter}.
@@ -175,10 +175,11 @@ the source code from
 @enumerate
 
 @item
-Make sure that @command{convert-ly} script and the
-@command{lilypond} binary are a
-bleeding edge version -- the latest release or even better, a fresh
-snapshot from Git master.
+Make sure that @command{convert-ly} script and the @command{lilypond}
+binary are a bleeding edge version -- the latest release or even
+better, a fresh snapshot from Git master, with the environment
+variable @code{LILYPOND_BUILD_DIR} correctly set up, see
+@ref{Environment variables}.
 
 @item
 Start by creating a list of updated snippets from your local
@@ -189,16 +190,15 @@ scripts/auxiliar/makelsr.py
 @end example
 
 Commit the changes and make a patch.  Check the patch has nothing
-other than minor changes - in particular changes to the commitish
-for translations.  If all is good and you're confident in what
+other than minor changes.  If all is good and you're confident in what
 you've done, this can be pushed directly to staging.
 
 @item
-Next, download the updated snippets and run makelsr against them.
-From the top source directory, run:
+Next, download the updated snippets and run @command{makelsr.py}
+against them.  From the top source directory, run:
 
 @smallexample
-wget http://lsr.dsi.unimi.it/download/lsr-snippets-docs-`date +%F`.tar.gz
+wget http://lsr.di.unimi.it/download/lsr-snippets-docs-`date +%F`.tar.gz
 tar -xzf lsr-snippets-docs-`date +%F`.tar.gz
 make -C $LILYPOND_BUILD_DIR
 scripts/auxiliar/makelsr.py lsr-snippets-docs-`date +%F`
@@ -250,7 +250,8 @@ If there is any doubt about any of the files, you are strongly
 advised to run a review on Rietveld.
 
 @item
-If a Review is not needed, commit the changes and push to staging.
+If a Review is not needed, commit the changes and push to
+@code{staging}.
 
 @end enumerate
 
@@ -275,10 +276,11 @@ or log, then fix the file @file{Documentation/snippets/@var{foo}.ly} to make the
 documentation build successfully.
 
 @item
-Determine where it comes from by looking at its first line, e.g. run
+Determine where it comes from by looking at its first two lines,
+e.g. run
 
 @example
-head -1 Documentation/snippets/@var{foo}.ly
+head -2 Documentation/snippets/@var{foo}.ly
 @end example
 
 @item
@@ -295,12 +297,21 @@ is simpler and recommended to write a new version of the snippet in
 @file{Documentation/snippets/new}, then run @command{makelsr.py}.
 
 @item
-@strong{If the snippet comes from}
-@file{Documentation/snippets/new}, apply the same fix in
-@file{Documentation/snippets/new/@var{foo}.ly} that you did in
-@file{Documentation/snippets/@var{foo}.ly}.  If the build failure
-was caused by a translation string, you may have to fix
-@file{input/texidocs/@var{foo}.texidoc} instead.
+@strong{If the snippet comes from} @file{Documentation/snippets/new},
+apply the fix in @file{Documentation/snippets/new/@var{foo}.ly}, then
+run @command{makelsr.py} without argument from top of the source tree:
+
+@example
+scripts/auxiliar/makelsr.py
+@end example
+
+Then, inspect @file{Documentation/snippets/@var{foo}.ly} to check that
+the fix has been well propagated.
+
+If the build failure was caused by a translation string, you may have
+to fix some @file{Documentation/@var{lang}/texidocs/@var{foo}.texidoc}
+instead; in case the build failure comes only from translation
+strings, it is not needed to run @command{makelsr.py}.
 
 @item
 When you've done, commit your changes to Git and ensure they're
@@ -349,7 +360,7 @@ updating the binary running the LSR.
 
 @item
 Download the latest snippet tarball from
-@uref{http://lsr.dsi.unimi.it/download/} and extract it.
+@uref{http://lsr.di.unimi.it/download/} and extract it.
 The relevant files can be found in the @file{all} subdirectory.
 Make sure your shell is using an English language version, for
 example @code{LANG=en_US}, then run @command{convert-ly} on all
@@ -383,23 +394,8 @@ convert-ly -e -t2.14.2 *.ly
 
 @item
 There might be no conversion rule for some old commands. To make
-an initial check for possible problems you can run the following
-script on a copy of the @file{all} subdirectory:
-
-@example
-#!/bin/bash
-
-for LILYFILE in *.ly
-do
-  STEM=$(basename "$LILYFILE" .ly)
-  echo "running $LILYFILE..."
-  convert-ly -e -t<version> "$LILYFILE" >& "$STEM".txt
-done
-
-grep refer *.txt
-grep smart *.txt
-TODO: better script
-@end example
+an initial check for possible problems you can run the
+script at the end of this list on a copy of the @file{all} subdirectory.
 
 @item
 Copy relevant snippets (i.e. snippets whose version is equal to
@@ -464,29 +460,54 @@ step by step.
 @end enumerate
 
 
-Below is a shell script to run all @file{.ly} files in a directory
-and redirect terminal output to text files, which are then
-searched for the word "failed" to see which snippets do not compile.
+Below is a shell script to run LilyPond on all @file{.ly} files in a directory.
+If the script is run with a -s parameter, it runs silently except for reporting
+failed files.  If run with -c it also runs @code{convert-ly} prior to running
+LilyPond.
 
 @smallexample
 #!/bin/bash
 
-for LILYFILE in *.ly
+while getopts sc opt; do
+    case $opt in
+        s)
+            silent=true
+            ;;
+        c)
+            convert=true
+            ;;
+    esac
+done
+param=$@
+if [ $silent ]; then
+    param=$@{param:3@}
+fi
+if [ $convert ]; then
+    param=$@{param:3@}
+fi
+filter=$@{param:-"*.ly"@}
+
+for LILYFILE in $filter
 do
-  STEM=$(basename "$LILYFILE" .ly)
-  echo "running $LILYFILE..."
-  lilypond --format=png -ddelete-intermediate-files "$LILYFILE" >& "$STEM".txt
+    STEM=$(basename "$LILYFILE" .ly)
+    if [ $convert ]; then
+        if [ $silent ]; then
+            $LILYPOND_BUILD_DIR/out/bin/convert-ly -e "$LILYFILE" >& "$STEM".con.txt
+        else
+            $LILYPOND_BUILD_DIR/out/bin/convert-ly -e "$LILYFILE"
+        fi
+    fi
+    if [ ! $silent ]; then
+        echo "running $LILYFILE..."
+    fi
+    $LILYPOND_BUILD_DIR/out/bin/lilypond --format=png "$LILYFILE" >& "$STEM".txt
+    RetVal=$?
+    if [ $RetVal -gt 0 ]; then
+       echo "$LILYFILE failed"
+    fi
 done
-
-grep failed *.txt
-TODO: better script
 @end smallexample
 
-Sometimes @code{grep failed *.txt} will not discover all
-problematic files. In addition you may want to use:
+Output from LilyPond is in @file{filename.txt} and convert-ly in
+@file{filename.con.txt}.
 
-@example
-grep ERROR *.txt
-grep error *.txt
-grep warning *.txt
-@end example