--- /dev/null
+@c -*- coding: utf-8; mode: texinfo; -*-
+
+@ignore
+ Translation of GIT committish: 0764a50d470cab82ca29da30298dacd333d3da12
+
+ When revising a translation, copy the HEAD committish of the
+ version that you are working on. For details, see the Contributors'
+ Guide, node Updating translation committishes..
+@end ignore
+
+@c \version "2.14.0"
+
+@node Vorschläge zum Schreiben von LilyPond-Eingabe-Dateien
+@chapter Vorschläge zum Schreiben von LilyPond-Eingabe-Dateien
+@translationof Suggestions for writing LilyPond input files
+
+Jetzt sind Sie so weit, größere Stücke mit LilyPond zu schreiben --
+nicht nur die kleinen Beispiele aus der Übung, sondern ganze Stücke.
+Aber wie geht man das am besten an?
+
+Solange LilyPond Ihre Dateien versteht und die Noten so setzt,
+wie Sie das wollen, spielt es eigentlich keine Rolle, wie Ihre
+Dateien aussehen. Es gibt aber trotzdem ein paar Dinge, die man
+beim Schreiben von LilyPond-Code berücksichtigen sollte.
+
+@itemize @bullet
+@item Was ist, wenn Sie einen Fehler machen? Die Struktur einer
+LilyPond-Datei kann es erleichtern (oder erschweren), bestimmte
+Fehler zu finden.
+
+@item Was ist, wenn Sie Ihre Dateien mit jemandem austauschen
+wollen? Oder Ihre Dateien nach einige Jahren noch einmal überarbeiten
+wollen? Manche LilyPond-Dateien versteht man auf den ersten Blick,
+über anderen muss man eine Stunde grübeln, um die Struktur zu ahnen.
+
+@item Was ist, wenn sie Ihre Dateien auf eine neuere LilyPond-Version
+aktualisieren wollen? Die Syntax der Eingabesprache verändert sich
+allmählich mit Verbesserungen im Programm. Die meisten Veränderungen
+können automatisch durch @code{convert-ly} gelöst werden, aber
+bestimmte Änderungen brauchen Handarbeit. LilyPond-Dateien können
+strukturiert werden, damit sie einfacher aktualisierbar sind.
+@end itemize
+
+@menu
+* Allgemeine Vorschläge::
+* Das Kopieren von bereits vorhandener Musik::
+* Große Projekte::
+* Problemlösung::
+* Make und Makefiles::
+@end menu
+
+
+@node Allgemeine Vorschläge
+@section Allgemeine Vorschläge
+@translationof General suggestions
+
+Hier einige Vorschläge, wie Sie Probleme vermeiden oder lösen können:
+
+@itemize
+@item @strong{Schreiben Sie immer mit @code{\version} die
+Versionsnummer
+in jede Datei}. Beachten Sie, dass in allen Vorlagen die Versionsnummer
+@code{\version "2.14.0"} eingetragen ist. Es empfiehlt sich, in alle
+Dateien, unabhängig von ihrer Größe, den @code{\version}-Befehl
+einzufügen. Persönliche Erfahrung hat gezeigt, dass es ziemlich
+frustrierend sein kann zu erinnern, welche Programmversion man etwa
+vor einem Jahr verwendet hat. Auch @code{convert-ly} benötigt die
+Versionsnummer.
+
+@item @strong{Benutzen Sie Überprüfungen}: @ruser{Oktavenüberprüfung}, und
+@ruser{Takt- und Taktzahlüberprüfung}. Wenn Sie hier und da diese
+Überprüfungen einfügen, finden Sie einen möglichen Fehler weit
+schneller. Wie oft aber ist @qq{hier und da}? Das hängt von der
+Komplexität der Musik ab. ei einfachen Stücken reicht es vielleicht
+ein- oder zweimal, in sehr komplexer Musik sollte man sie vielleicht
+in jeden Takt einfügen.
+
+@item @strong{Ein Takt pro Textzeile}. Wenn irgendetwas kompliziertes
+vorkommt, entweder in der Musik selber oder in der Anpassung der
+Ausgabe,
+empfiehlt es sich oft, nur einen Takt pro Zeile zu schreiben.
+Bildschirmplatz zu sparen, indem Sie acht Takte in eine Zeile zwängen,
+hilft nicht weiter, wenn Sie ihre Datei @qq{debuggen} müssen.
+
+@item @strong{Kommentieren Sie ihre Dateien}. Benutzen Sie entweder
+Taktnummern (in regelmäßigen Abständen) oder Verweise auf musikalische
+Themen (@qq{Zweites Thema in den Geigen}, @qq{vierte Variation} usw.).
+Sie brauchen diese Kommentare vielleicht noch nicht, wenn Sie das Stück
+notieren, aber spätestens wenn Sie nach ein paar Jahren etwas
+verändern
+wollen oder Sie den Quelltext an einen Freund weitergeben wollen,
+ist es weitaus komplizierter, die Dateistruktur ohne Kommentare zu
+verstehen, als wenn Sie sie rechtzeitig eingefügt hätten.
+
+@item @strong{Schreiben Sie Klammern mit Einrückung}. Viele
+Probleme entstehen durch ungerade Anzahl von @code{@{} und
+@code{@}}-Klammern.
+
+@item @strong{Schreiben Sie Tondauerangaben} am Anfang von
+Abschnitten und Bezeichnern. Wenn Sie beispielsweise
+ @code{c4 d e} am Anfang eines Abschnittes schreiben,
+ersparen Sie sich viele Probleme, wenn Sie ihre Musik
+eines Tages umarrangieren wollen.
+
+@item @strong{Trennen Sie Einstellungen} von den eigentlichen
+Noten. Siehe auch @rlearning{Tipparbeit durch Variablen und Funktionen ersparen}
+und
+@rlearning{Globale Formatierung}.
+
+@end itemize
+
+
+@node Das Kopieren von bereits vorhandener Musik
+@section Das Kopieren von bereits vorhandener Musik
+@translationof Typesetting existing music
+
+Wenn Sie Musik aus einer fertigen Partitur kopieren (z. B. die
+LilyPond-Eingabe einer gedruckten Partitur):
+
+@itemize
+
+@item
+Schreiben Sie ein System ihrer Quelle nach dem anderen
+(aber trotzdem nur einen Takt pro Textzeile) und überprüfen
+Sie jedes System, nachdem Sie es fertig kopiert haben. Mit dem
+@code{showLastLength}- oder @code{showFirstLenght}-Befehl können Sie den Übersetzungsprozess
+beschleunigen. Siehe auch
+@ruser{Korrigierte Musik überspringen}.
+
+@item
+Definieren Sie @code{mBreak = @{ \break @}} und schreiben Sie
+ @code{\mBreak} in der Quelldatei immer dann, wenn im Manuskript
+ein Zeilenumbruch vorkommt. Das macht es einfacher, die gesetzte
+Zeile mit den ursprünglichen Noten zu vergleichen. Wenn Sie die
+Partitur fertig gestellt haben, könne Sie @code{mBreak = @{ @}},
+also leer definieren, um diese manuellen Zeilenumbrüche zu entfernen.
+Damit kann dann LilyPond selber entscheiden, wohin es passende
+Zeilenumbrüche platziert.
+
+@item
+Wenn Sie eine Stimme für ein transponierendes Instrument als eine
+Variable notieren, wird empfohlen, dass die Noten von
+
+@example
+\transpose c klingende-Tonhöhe @{...@}
+@end example
+
+eingefasst werden (wobei @code{klingende-Tonhöhe} die klingende Tonhöhe
+des Instruments ist), sodass die Noten innerhalb der Variable für klingendes C
+geschrieben sind. Sie können die Variable zurücktransponieren, wenn es
+nötig ist, aber Sie müssen es nicht tun. Fehler in Transpositionen sind
+treten seltener auf, wenn alle Noten in den Variablen für die gleiche
+Ausgangstonhöhe geschrieben werden.
+
+Denken Sie auch daran, dass Sie nur von/nach C transponieren. Das heißt,
+dass die einzigen anderen Tonhöhen, die Sie in Transpositionen benutzen,
+die Tonhöhen der Instrumente sind, für die Sie schreiben: @code{bes} für
+eine B-Trompete oder @code{aes} für eine As-Klarinette usw.
+
+@end itemize
+
+
+@node Große Projekte
+@section Große Projekte
+@translationof Large projects
+
+Besonders wenn Sie an größeren Projekten arbeiten, ist es
+unumgänglich, dass Sie ihre LilyPond-Dateien klar strukturieren.
+
+@itemize
+
+@item @strong{Verwenden Sie Variablen für jede Stimme}, innerhalb
+der Definition sollte so wenig Struktur wie möglich sein. Die
+Struktur des @code{\score}-Abschnittes verändert sich am ehesten,
+während die @code{violine}-Definition sich wahrscheinlich mit einer
+neuen Programmversion nicht verändern wird.
+
+@example
+violine = \relative c'' @{
+g4 c'8. e16
+@}
+...
+\score @{
+ \new GrandStaff @{
+ \new Staff @{
+ \violine
+ @}
+ @}
+@}
+@end example
+
+@item @strong{Trennen Sie Einstellungen von den Noten}. Diese
+Empfehlung wurde schon früher gegeben,
+aber für große Projekte ist es unumgänglich. Muss z. B. die
+Definition für @code{fdannp} verändert werden, so braucht
+man es nur einmal vorzunehmen und die Noten in der Geigenstimme,
+@code{violin}, bleiben unberührt.
+
+@example
+fdannp = _\markup@{
+ \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
+violin = \relative c'' @{
+g4\fdannp c'8. e16
+@}
+@end example
+
+@end itemize
+
+
+
+@node Fehlersuche
+@section Fehlersuche
+@translationof Troubleshooting
+
+Früher oder später werden Sie in die Lage kommen,
+dass LilyPond Ihre Datei nicht kompilieren will. Die
+Information, die LilyPond während der Übersetzung
+gibt, können Ihnen helfen, den Fehler zu finden, aber
+in vielen Fällen müssen Sie nach der Fehlerquelle
+auf die Suche gehen.
+
+Die besten Hilfsmittel sind in diesem Fall das Zeilen-
+und Blockkommentar (angezeigt durch @code{%} bzw.
+@code{%@{ ... %@}}). Wenn Sie nicht bestimmen können,
+wo sich das Problem befindet, beginnen Sie damit, große
+Teile des Quelltextes auszukommentieren. Nachdem Sie
+einen Teil auskommentiert haben, versuchen Sie, die Datei
+erneut zu übersetzen. Wenn es jetzt funktioniert, muss
+sich das Problem innerhalb der Kommentare befinden.
+Wenn es nicht funktioniert, müssen Sie weitere Teile
+auskommentieren bis sie eine Version haben, die funktioniert.
+
+In Extremfällen bleibt nur noch solch ein Beispiel übrig:
+
+@example
+\score @{
+ <<
+ % \melody
+ % \harmony
+ % \bass
+ >>
+ \layout@{@}
+@}
+@end example
+
+@noindent
+(also eine Datei ohne Noten).
+
+Geben Sie nicht auf, wenn das vorkommen sollte. Nehmen
+Sie das Kommentarzeichen von einem Teil wieder weg, sagen
+wir der Bassstimme, und schauen Sie, ob es funktioniert.
+Wenn nicht, dann kommentieren Sie die gesamte Bassstimme
+aus, aber nicht den @code{\bass}-Befehl in dem
+ @code{\score}-Abschnitt:
+
+@example
+bass = \relative c' @{
+%@{
+ c4 c c c
+ d d d d
+%@}
+@}
+@end example
+
+Jetzt beginnen Sie damit, langsam Stück für Stück der
+Bassstimme wieder hineinzunehmen, bis Sie die problematische
+Zeile finden.
+
+Eine andere nützliche Technik zur Problemlösung ist es,
+@rweb{Minimalbeispiele} zu konstruieren.
+
+
+
+@node Make und Makefiles
+@section Make und Makefiles
+@translationof Make and Makefiles
+
+@cindex Makefile
+@cindex Make-Dateien
+@cindex make
+
+Fast alle Betriebssysteme, auf denen LilyPond benutzt werden kann,
+unterstützen ein Programm mit dem Namen @code{make}. Dieses Programm
+liest eine besondere Datei mit der Bezeichnung @code{Makefile},
+die definiert, welche Dateien von welchen anderen Dateien abhängen und
+welche Befehle für das Betriebssystem nötig sind, um eine Datei aus
+einer anderen zu erstellen. Ein Makefile könnte etwa erklären, wie
+@file{ballad.pdf} und @file{ballad.midi} aus @file{ballad.ly}
+erstellt werden können, indem LilyPond aufgerufen wird.
+
+Es gibt Fällen, wenn es sich sehr stark empfiehlt, ein @code{Makefile}
+für das aktuelle Projekt zu erstellen, entweder zur eigenen Bequemlichkeit,
+oder aber auch als Hilfe für andere, die vielleicht einmal die
+Quelldateien lesen und verstehen wollen. Insbesondere bei großen Projekten
+mit vielen eingefügten Dateien und unterschiedlichen Ausgabeoptionen
+(etwa Partitur, einzelne Stimmen, Dirigierpartitur, Klavierauszug usw.),
+aber auch bei Projekten, die komplizierte Programmaufrufe zur Verarbeitung
+erfordern (wenn man etwa mit @code{lilypond-book} arbeitet), lohnt
+sich die Erstellung einer Make-Datei. Diese Dateien können sehr
+unterschiedliche ausfallen, und ihre Komplexität und Flexibilität kann
+den Bedürfnissen aber auch Kenntnissen des Schreibers angepasst werden.
+Das Programm GNU Make ist auf GNU/Linux Distributionen und MacOS X
+installiert, aber es ist auch für Windows erhältlich.
+
+Das @strong{GNU Make Manual} gibt eine vollständige Anleitung, wie
+@code{make} benutzt werden kann. Hier sollen nur einige kleine
+Blicke auf die vielfältigen Möglichkeiten geworfen werden.
+
+Die Befehle, um Regeln in einer Make-Datei zu erstellen, unterscheidet
+sich zwischen den Betriebssystemen. Die verschiedenen Linuxe und
+MacOS X benutzen @code{bash}, während unter Windows @code{cmd} eingesetzt
+wird. Unter MacOS X muss man das System so konfigurieren, dass
+die Kommandozeile benutzt wird. Hier einige Beispiele für Make-Dateien,
+mit Versionen für Linux/MacOS und Windows.
+
+Das erste Beispiel ist für ein Orchesterstück in vier Stätzen unt mit
+der folgenden Dateistruktur:
+
+@example
+Symphony/
+|-- MIDI/
+|-- Makefile
+|-- Notes/
+| |-- cello.ily
+| |-- figures.ily
+| |-- horn.ily
+| |-- oboe.ily
+| |-- trioString.ily
+| |-- viola.ily
+| |-- violinOne.ily
+| `-- violinTwo.ily
+|-- PDF/
+|-- Parts/
+| |-- symphony-cello.ly
+| |-- symphony-horn.ly
+| |-- symphony-oboes.ly
+| |-- symphony-viola.ly
+| |-- symphony-violinOne.ly
+| `-- symphony-violinTwo.ly
+|-- Scores/
+| |-- symphony.ly
+| |-- symphonyI.ly
+| |-- symphonyII.ly
+| |-- symphonyIII.ly
+| `-- symphonyIV.ly
+`-- symphonyDefs.ily
+@end example
+
+Die @file{.ly}-Dateien un den Verzeichnissen @file{Scores} und
+@file{Parts} erhalten ihrere Noten aus @file{.ily}-Dateien, die
+sich im @file{Notes}-Verzeichnis befinden:
+
+@example
+%%% Kopfzeile der Datei "symphony-cello.ly"
+\include ../definitions.ily
+\include ../Notes/cello.ily
+@end example
+
+Die Make-Datei hat die Ziele @code{score} (das gesamte Stück als
+große Partitur), @code{movements} (die einzelnen Sätze als große
+Partitur) und @code{parts} (die einzelnen Stimmen für die Spieler).
+Es gibt auch das Ziel @code{archive}, welches ein Tar-Archiv
+der Quelldateien erstellt, etwa um die Quellen über das Internet
+oder per E-Mail zu verteilen. Hier die Make-Datei für GNU/Linux
+oder MacOS X. Sie sollte unter dem Namen @code{Makefile} im obersten
+Verzeichnis des Projektes gespeichert werden:
+
+@warning{Wenn ein Ziel oder eine Musterregel definiert ist, müssen
+die folgenden Zeilen mit Tabulatoren, nicht mit Leerzeichen beginnen.}
+
+@example
+# Namensstamm der Ausgabedateien
+piece = symphony
+# finde heraus, wieviele Prozessoren vorhanden sind
+CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//`
+# Der Befehl, um lilypond aufzurufen
+LILY_CMD = lilypond -ddelete-intermediate-files \
+ -dno-point-and-click -djob-count=$(CPU_CORES)
+
+# Die Endungen, die im Makefile benutzt werden
+.SUFFIXES: .ly .ily .pdf .midi
+
+# Eingabe- und Ausgabedateien werden in den Verzeichnissen durchsucht,
+# die sich in der VPATH-Variable befinden. Alle sind Unterverzeichnisse
+# des aktuellen Verzeichnisses (angegeben durch die GNU make-Variable
+# `CURDIR').
+VPATH = \
+ $(CURDIR)/Scores \
+ $(CURDIR)/PDF \
+ $(CURDIR)/Parts \
+ $(CURDIR)/Notes
+
+# Die Musterregel, um PDF und MIDI-Dateien aus der LY-Eingabedatei
+# zu erstellen. Die .pdf-Ausgabedateien werden in das
+# `PDF'-Unterverzeichnis abgelegt, die .midi-Dateien in das
+# `MIDI'-Unterverzeichnis.
+%.pdf %.midi: %.ly
+ $(LILY_CMD) $<; \ # this line begins with a tab
+ if test -f "$*.pdf"; then \
+ mv "$*.pdf" PDF/; \
+ fi; \
+ if test -f "$*.midi"; then \
+ mv "$*.midi" MIDI/; \
+ fi
+
+notes = \
+ cello.ily \
+ horn.ily \
+ oboe.ily \
+ viola.ily \
+ violinOne.ily \
+ violinTwo.ily
+
+# Abhängigkeiten der einzelnen Sätze.
+$(piece)I.pdf: $(piece)I.ly $(notes)
+$(piece)II.pdf: $(piece)II.ly $(notes)
+$(piece)III.pdf: $(piece)III.ly $(notes)
+$(piece)IV.pdf: $(piece)IV.ly $(notes)
+
+# Abhängigkeiten der großen Partitur.
+$(piece).pdf: $(piece).ly $(notes)
+
+# Abhängigkeiten der Stimmen.
+$(piece)-cello.pdf: $(piece)-cello.ly cello.ily
+$(piece)-horn.pdf: $(piece)-horn.ly horn.ily
+$(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
+$(piece)-viola.pdf: $(piece)-viola.ly viola.ily
+$(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
+$(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
+
+# `make score' eintippen, um die große Partitur mit allen vier
+# Sätzen als eine Datei zu erstellen.
+.PHONY: score
+score: $(piece).pdf
+
+# `make parts' tippen, um alle Stimmen zu erstellen.
+# `make foo.pdf' tippen, um die Stimme für das Instrument `foo' zu erstellen.
+# Beispiel: `make symphony-cello.pdf'.
+.PHONY: parts
+parts: $(piece)-cello.pdf \
+ $(piece)-violinOne.pdf \
+ $(piece)-violinTwo.pdf \
+ $(piece)-viola.pdf \
+ $(piece)-oboes.pdf \
+ $(piece)-horn.pdf
+
+# `make movements' tippen um Dateien für die vier Sätze einzeln zu erstellen.
+.PHONY: movements
+movements: $(piece)I.pdf \
+ $(piece)II.pdf \
+ $(piece)III.pdf \
+ $(piece)IV.pdf
+
+all: score parts movements
+
+archive:
+ tar -cvvf stamitz.tar \ # this line begins with a tab
+ --exclude=*pdf --exclude=*~ \
+ --exclude=*midi --exclude=*.tar \
+ ../Stamitz/*
+@end example
+
+Unter Windows ergeben sich bestimmte Komplikationen. Nachdem man
+GNU Make für Windows heruntergeladen und installiert hat, muss
+man den richtigen Pfad in den Umgebungsvariablen des Systems setzen,
+damit die DOS-Kommandozeile das Make-Programm finden kann. Um das
+vorzunehmen, kann mit der rechten Maustaste auf "Arbeitsplatz"
+klicken, dann @code{Eigenschaften} und @code{Erweitert} geklickt
+werden. Hier wählt man @code{Umgebungsvariablen}. In der
+Liste @code{Systemvariablen} wählt man @code{Path} und mit
+einem Klick auf @code{Bearbeiten} kann man den Pfad zu der
+@code{.exe}-Datei von GNU Make hinzufügen, der etwa wie
+folgt aussieht:
+
+@example
+C:\Program Files\GnuWin32\bin
+@end example
+
+Die Make-Datei selber muss auch angepasst werden, um unterschiedliche
+Shell-Befehle zu verwenden und mit Leerzeichen umgehen zu können,
+die sich in einigen Standardverzeichnissen unter Windows befinden.
+Das @code{archive}-Ziel wird entfernt, da Windows den
+@code{tar}-Befehl nicht kennt, und Windows benutzt auch eine
+andere Dateiendung für midi-Dateien.
+
+
+@example
+## WINDOWS VERSION
+##
+piece = symphony
+LILY_CMD = lilypond -ddelete-intermediate-files \
+ -dno-point-and-click \
+ -djob-count=$(NUMBER_OF_PROCESSORS)
+
+# 8.3 Bezeichnung für CURDIR erhalten (Workaround wg. Leerzeichen in PATH)
+workdir = $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \
+ do @@echo %%~sb)
+
+.SUFFIXES: .ly .ily .pdf .mid
+
+VPATH = \
+ $(workdir)/Scores \
+ $(workdir)/PDF \
+ $(workdir)/Parts \
+ $(workdir)/Notes
+
+%.pdf %.mid: %.ly
+ $(LILY_CMD) $< # diese Zeile beginnt mit Tabulator
+ if exist "$*.pdf" move /Y "$*.pdf" PDF/ # begin with tab
+ if exist "$*.mid" move /Y "$*.mid" MIDI/ # begin with tab
+
+notes = \
+ cello.ily \
+ figures.ily \
+ horn.ily \
+ oboe.ily \
+ trioString.ily \
+ viola.ily \
+ violinOne.ily \
+ violinTwo.ily
+
+$(piece)I.pdf: $(piece)I.ly $(notes)
+$(piece)II.pdf: $(piece)II.ly $(notes)
+$(piece)III.pdf: $(piece)III.ly $(notes)
+$(piece)IV.pdf: $(piece)IV.ly $(notes)
+
+$(piece).pdf: $(piece).ly $(notes)
+
+$(piece)-cello.pdf: $(piece)-cello.ly cello.ily
+$(piece)-horn.pdf: $(piece)-horn.ly horn.ily
+$(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
+$(piece)-viola.pdf: $(piece)-viola.ly viola.ily
+$(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
+$(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
+
+.PHONY: score
+score: $(piece).pdf
+
+.PHONY: parts
+parts: $(piece)-cello.pdf \
+ $(piece)-violinOne.pdf \
+ $(piece)-violinTwo.pdf \
+ $(piece)-viola.pdf \
+ $(piece)-oboes.pdf \
+ $(piece)-horn.pdf
+
+.PHONY: movements
+movements: $(piece)I.pdf \
+ $(piece)II.pdf \
+ $(piece)III.pdf \
+ $(piece)IV.pdf
+
+all: score parts movements
+@end example
+
+Die nächste Make-Datei ist für ein @command{lilypond-book}-Dokument,
+das in LaTeX gesetzt wird. Das Projekt hat einen Index, welcher
+erfordert, dass der Befehl @command{latex} zweimal aufgerufen wird,
+um die Verweise zu aktualisieren. Ausgabedateien werden in einem
+@code{out}-Verzeichnis für die .pdf-Dateien gespeichert und in
+@code{htmlout} für die html-Dateien.
+
+@example
+SHELL=/bin/sh
+FILE=myproject
+OUTDIR=out
+WEBDIR=htmlout
+VIEWER=acroread
+BROWSER=firefox
+LILYBOOK_PDF=lilypond-book --output=$(OUTDIR) --pdf $(FILE).lytex
+LILYBOOK_HTML=lilypond-book --output=$(WEBDIR) $(FILE).lytex
+PDF=cd $(OUTDIR) && pdflatex $(FILE)
+HTML=cd $(WEBDIR) && latex2html $(FILE)
+INDEX=cd $(OUTDIR) && makeindex $(FILE)
+PREVIEW=$(VIEWER) $(OUTDIR)/$(FILE).pdf &
+
+all: pdf web keep
+
+pdf:
+ $(LILYBOOK_PDF) # begin with tab
+ $(PDF) # begin with tab
+ $(INDEX) # begin with tab
+ $(PDF) # begin with tab
+ $(PREVIEW) # begin with tab
+
+web:
+ $(LILYBOOK_HTML) # begin with tab
+ $(HTML) # begin with tab
+ cp -R $(WEBDIR)/$(FILE)/ ./ # begin with tab
+ $(BROWSER) $(FILE)/$(FILE).html & # begin with tab
+
+keep: pdf
+ cp $(OUTDIR)/$(FILE).pdf $(FILE).pdf # begin with tab
+
+clean:
+ rm -rf $(OUTDIR) # begin with tab
+
+web-clean:
+ rm -rf $(WEBDIR) # begin with tab
+
+archive:
+ tar -cvvf myproject.tar \ # begin this line with tab
+ --exclude=out/* \
+ --exclude=htmlout/* \
+ --exclude=myproject/* \
+ --exclude=*midi \
+ --exclude=*pdf \
+ --exclude=*~ \
+ ../MyProject/*
+@end example
+
+TODO: soll auch unter Windows funktionieren
+
+Die vorige Make-Datei funktioniert nicht unter Windows. Als Alternative
+für Windows-Benutzer könnte man eine einfache batch-Datei erstellen,
+welche die erforderlichen Befehl enthält. Sie kümmert sich nicht
+um Abhängigkeiten, wie es eine Make-Datei kann, aber wenigstens
+wird die Kompilation auf einen einzigen Befehl beschränkt. Das folgende
+kann als Datei @command{build.bat} oder @command{build.cmd} gespeichert
+werden. Die Batch-Datei kann auf der Kommandozeile aufgerufen werden
+oder einfach doppelt angeklickt werden.
+
+@example
+lilypond-book --output=out --pdf myproject.lytex
+cd out
+pdflatex myproject
+makeindex myproject
+pdflatex myproject
+cd ..
+copy out\myproject.pdf MyProject.pdf
+@end example
+
+
+@seealso
+Programmbenutzung:
+@rprogram{Benutzung auf der Kommandozeile},
+@rprogram{lilypond-book}.
+
projects / lilypond.git / blobdiff