@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.19.21"

@node Návrhy pro psaní vstupních souborů LilyPond
@chapter Návrhy pro psaní vstupních souborů LilyPond
@translationof Suggestions for writing 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
* Všeobecné návrhy::
* Kopírování stávající hudby::
* Velké projekty::
* Řešení potíží::
* Make a Makefiles::
@end menu


@node Všeobecné návrhy
@section Všeobecné návrhy
@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.19.21"} 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 Kopírování stávající hudby
@section Kopírování stávající hudby
@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 Velké projekty
@section Velké projekty
@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 @{
g'4 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 velké projekty 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 @{
g'4\fdannp c'8. e16
@}
@end example

@end itemize



@node Řešení potíží
@section Řešení potíží
@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'4 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 a Makefiles
@section Make a 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}.