Documentation/cs/usage/suggestions.itely

   1 @c -*- coding: utf-8; mode: texinfo; -*-
   2
   3 @ignore
   4     Translation of GIT committish: 0764a50d470cab82ca29da30298dacd333d3da12
   5
   6     When revising a translation, copy the HEAD committish of the
   7     version that you are working on.  For details, see the Contributors'
   8     Guide, node Updating translation committishes..
   9 @end ignore
  10
  11 @c \version "2.14.0"
  12
  13 @node Návrhy pro psaní vstupních souborů LilyPond
  14 @chapter Návrhy pro psaní vstupních souborů LilyPond
  15 @translationof Suggestions for writing LilyPond input files
  16
  17 Jetzt sind Sie so weit, größere Stücke mit LilyPond zu schreiben --
  18 nicht nur die kleinen Beispiele aus der Übung, sondern ganze Stücke.
  19 Aber wie geht man das am besten an?
  20
  21 Solange LilyPond Ihre Dateien versteht und die Noten so setzt,
  22 wie Sie das wollen, spielt es eigentlich keine Rolle, wie Ihre
  23 Dateien aussehen.  Es gibt aber trotzdem ein paar Dinge, die man
  24 beim Schreiben von LilyPond-Code berücksichtigen sollte.
  25
  26 @itemize @bullet
  27 @item Was ist, wenn Sie einen Fehler machen?  Die Struktur einer
  28 LilyPond-Datei kann es erleichtern (oder erschweren), bestimmte
  29 Fehler zu finden.
  30
  31 @item Was ist, wenn Sie Ihre Dateien mit jemandem austauschen
  32 wollen?  Oder Ihre Dateien nach einige Jahren noch einmal überarbeiten
  33 wollen?  Manche LilyPond-Dateien versteht man auf den ersten Blick,
  34 über anderen muss man eine Stunde grübeln, um die Struktur zu ahnen.
  35
  36 @item Was ist, wenn sie Ihre Dateien auf eine neuere LilyPond-Version
  37 aktualisieren wollen?  Die Syntax der Eingabesprache verändert sich
  38 allmählich mit Verbesserungen im Programm.  Die meisten Veränderungen
  39 können automatisch durch @code{convert-ly} gelöst werden, aber
  40 bestimmte Änderungen brauchen Handarbeit.  LilyPond-Dateien können
  41 strukturiert werden, damit sie einfacher aktualisierbar sind.
  42 @end itemize
  43
  44 @menu
  45 * Všeobecné návrhy::
  46 * Kopírování stávající hudby::
  47 * Velké projekty::
  48 * Řešení potíží::
  49 * Make a Makefiles::
  50 @end menu
  51
  52
  53 @node Všeobecné návrhy
  54 @section Všeobecné návrhy
  55 @translationof General suggestions
  56
  57 Hier einige Vorschläge, wie Sie Probleme vermeiden oder lösen können:
  58
  59 @itemize
  60 @item @strong{Schreiben Sie immer mit @code{\version} die
  61 Versionsnummer
  62 in jede Datei}.  Beachten Sie, dass in allen Vorlagen die Versionsnummer
  63 @code{\version "2.14.0"} eingetragen ist.  Es empfiehlt sich, in alle
  64 Dateien, unabhängig von ihrer Größe, den @code{\version}-Befehl
  65 einzufügen.  Persönliche Erfahrung hat gezeigt, dass es ziemlich
  66 frustrierend sein kann zu erinnern, welche Programmversion man etwa
  67 vor einem Jahr verwendet hat.  Auch @code{convert-ly} benötigt die
  68 Versionsnummer.
  69
  70 @item @strong{Benutzen Sie Überprüfungen}: @ruser{Oktavenüberprüfung}, und
  71 @ruser{Takt- und Taktzahlüberprüfung}.  Wenn Sie hier und da diese
  72 Überprüfungen einfügen, finden Sie einen möglichen Fehler weit
  73 schneller.  Wie oft aber ist @qq{hier und da}?  Das hängt von der
  74 Komplexität der Musik ab.  ei einfachen Stücken reicht es vielleicht
  75 ein- oder zweimal, in sehr komplexer Musik sollte man sie vielleicht
  76 in jeden Takt einfügen.
  77
  78 @item @strong{Ein Takt pro Textzeile}.  Wenn irgendetwas kompliziertes
  79 vorkommt, entweder in der Musik selber oder in der Anpassung der
  80 Ausgabe,
  81 empfiehlt es sich oft, nur einen Takt pro Zeile zu schreiben.
  82 Bildschirmplatz zu sparen, indem Sie acht Takte in eine Zeile zwängen,
  83 hilft nicht weiter, wenn Sie ihre Datei @qq{debuggen} müssen.
  84
  85 @item @strong{Kommentieren Sie ihre Dateien}.  Benutzen Sie entweder
  86 Taktnummern (in regelmäßigen Abständen) oder Verweise auf musikalische
  87 Themen (@qq{Zweites Thema in den Geigen}, @qq{vierte Variation} usw.).
  88 Sie brauchen diese Kommentare vielleicht noch nicht, wenn Sie das Stück
  89 notieren, aber spätestens wenn Sie nach ein paar Jahren etwas
  90 verändern
  91 wollen oder Sie den Quelltext an einen Freund weitergeben wollen,
  92 ist es weitaus komplizierter, die Dateistruktur ohne Kommentare zu
  93 verstehen, als wenn Sie sie rechtzeitig eingefügt hätten.
  94
  95 @item @strong{Schreiben Sie Klammern mit Einrückung}.  Viele
  96 Probleme entstehen durch ungerade Anzahl von  @code{@{} und
  97 @code{@}}-Klammern.
  98
  99 @item @strong{Schreiben Sie Tondauerangaben} am Anfang von
 100 Abschnitten und Bezeichnern.  Wenn Sie beispielsweise
 101  @code{c4 d e} am Anfang eines Abschnittes schreiben,
 102 ersparen Sie sich viele Probleme, wenn Sie ihre Musik
 103 eines Tages umarrangieren wollen.
 104
 105 @item @strong{Trennen Sie Einstellungen} von den eigentlichen
 106 Noten.  Siehe auch @rlearning{Tipparbeit durch Variablen und Funktionen ersparen}
 107 und
 108 @rlearning{Globale Formatierung}.
 109
 110 @end itemize
 111
 112
 113 @node Kopírování stávající hudby
 114 @section Kopírování stávající hudby
 115 @translationof Typesetting existing music
 116
 117 Wenn Sie Musik aus einer fertigen Partitur kopieren (z. B. die
 118 LilyPond-Eingabe einer gedruckten Partitur):
 119
 120 @itemize
 121
 122 @item
 123 Schreiben Sie ein System ihrer Quelle nach dem anderen
 124 (aber trotzdem nur einen Takt pro Textzeile) und überprüfen
 125 Sie jedes System, nachdem Sie es fertig kopiert haben.  Mit dem
 126 @code{showLastLength}- oder @code{showFirstLenght}-Befehl können Sie den Übersetzungsprozess
 127 beschleunigen. Siehe auch
 128 @ruser{Korrigierte Musik überspringen}.
 129
 130 @item
 131 Definieren Sie @code{mBreak = @{ \break @}} und schreiben Sie
 132  @code{\mBreak} in der Quelldatei immer dann, wenn im Manuskript
 133 ein Zeilenumbruch vorkommt.  Das macht es einfacher, die gesetzte
 134 Zeile mit den ursprünglichen Noten zu vergleichen.  Wenn Sie die
 135 Partitur fertig gestellt haben, könne Sie  @code{mBreak = @{ @}},
 136 also leer definieren, um diese manuellen Zeilenumbrüche zu entfernen.
 137 Damit kann dann LilyPond selber entscheiden, wohin es passende
 138 Zeilenumbrüche platziert.
 139
 140 @item
 141 Wenn Sie eine Stimme für ein transponierendes Instrument als eine
 142 Variable notieren, wird empfohlen, dass die Noten von
 143
 144 @example
 145 \transpose c klingende-Tonhöhe @{...@}
 146 @end example
 147
 148 eingefasst werden (wobei @code{klingende-Tonhöhe} die klingende Tonhöhe
 149 des Instruments ist), sodass die Noten innerhalb der Variable für klingendes C
 150 geschrieben sind.  Sie können die Variable zurücktransponieren, wenn es
 151 nötig ist, aber Sie müssen es nicht tun.  Fehler in Transpositionen sind
 152 treten seltener auf, wenn alle Noten in den Variablen für die gleiche
 153 Ausgangstonhöhe geschrieben werden.
 154
 155 Denken Sie auch daran, dass Sie nur von/nach C transponieren.  Das heißt,
 156 dass die einzigen anderen Tonhöhen, die Sie in Transpositionen benutzen,
 157 die Tonhöhen der Instrumente sind, für die Sie schreiben: @code{bes} für
 158 eine B-Trompete oder @code{aes} für eine As-Klarinette usw.
 159
 160 @end itemize
 161
 162
 163 @node Velké projekty
 164 @section Velké projekty
 165 @translationof Large projects
 166
 167 Besonders wenn Sie an größeren Projekten arbeiten, ist es
 168 unumgänglich, dass Sie ihre LilyPond-Dateien klar strukturieren.
 169
 170 @itemize
 171
 172 @item @strong{Verwenden Sie Variablen für jede Stimme}, innerhalb
 173 der Definition sollte so wenig Struktur wie möglich sein.  Die
 174 Struktur des @code{\score}-Abschnittes verändert sich am ehesten,
 175 während die @code{violine}-Definition sich wahrscheinlich mit einer
 176 neuen Programmversion nicht verändern wird.
 177
 178 @example
 179 violine = \relative c'' @{
 180 g4 c'8. e16
 181 @}
 182 ...
 183 \score @{
 184   \new GrandStaff @{
 185     \new Staff @{
 186       \violine
 187     @}
 188   @}
 189 @}
 190 @end example
 191
 192 @item @strong{Trennen Sie Einstellungen von den Noten}.  Diese
 193 Empfehlung wurde schon früher gegeben,
 194 aber für velké projekty ist es unumgänglich.  Muss z. B. die
 195 Definition für @code{fdannp} verändert werden, so braucht
 196 man es nur einmal vorzunehmen und die Noten in der Geigenstimme,
 197 @code{violin}, bleiben unberührt.
 198
 199 @example
 200 fdannp = _\markup@{
 201   \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
 202 violin = \relative c'' @{
 203 g4\fdannp c'8. e16
 204 @}
 205 @end example
 206
 207 @end itemize
 208
 209
 210
 211 @node Řešení potíží
 212 @section Řešení potíží
 213 @translationof Troubleshooting
 214
 215 Früher oder später werden Sie in die Lage kommen,
 216 dass LilyPond Ihre Datei nicht kompilieren will.  Die
 217 Information, die LilyPond während der Übersetzung
 218 gibt, können Ihnen helfen, den Fehler zu finden, aber
 219 in vielen Fällen müssen Sie nach der Fehlerquelle
 220 auf die Suche gehen.
 221
 222 Die besten Hilfsmittel sind in diesem Fall das Zeilen-
 223 und Blockkommentar (angezeigt durch @code{%} bzw.
 224 @code{%@{ ... %@}}).  Wenn Sie nicht bestimmen können,
 225 wo sich das Problem befindet, beginnen Sie damit, große
 226 Teile des Quelltextes auszukommentieren.  Nachdem Sie
 227 einen Teil auskommentiert haben, versuchen Sie, die Datei
 228 erneut zu übersetzen.  Wenn es jetzt funktioniert, muss
 229 sich das Problem innerhalb der Kommentare befinden.
 230 Wenn es nicht funktioniert, müssen Sie weitere Teile
 231 auskommentieren bis sie eine Version haben, die funktioniert.
 232
 233 In Extremfällen bleibt nur noch solch ein Beispiel übrig:
 234
 235 @example
 236 \score @{
 237   <<
 238     % \melody
 239     % \harmony
 240     % \bass
 241   >>
 242   \layout@{@}
 243 @}
 244 @end example
 245
 246 @noindent
 247 (also eine Datei ohne Noten).
 248
 249 Geben Sie nicht auf, wenn das vorkommen sollte.  Nehmen
 250 Sie das Kommentarzeichen von einem Teil wieder weg, sagen
 251 wir der Bassstimme, und schauen Sie, ob es funktioniert.
 252 Wenn nicht, dann kommentieren Sie die gesamte Bassstimme
 253 aus, aber nicht den @code{\bass}-Befehl in dem
 254  @code{\score}-Abschnitt:
 255
 256 @example
 257 bass = \relative c' @{
 258 %@{
 259   c4 c c c
 260   d d d d
 261 %@}
 262 @}
 263 @end example
 264
 265 Jetzt beginnen Sie damit, langsam Stück für Stück der
 266 Bassstimme wieder hineinzunehmen, bis Sie die problematische
 267 Zeile finden.
 268
 269 Eine andere nützliche Technik zur Problemlösung ist es,
 270 @rweb{Minimalbeispiele} zu konstruieren.
 271
 272
 273
 274 @node Make a Makefiles
 275 @section Make a Makefiles
 276 @translationof Make and Makefiles
 277
 278 @cindex Makefile
 279 @cindex Make-Dateien
 280 @cindex make
 281
 282 Fast alle Betriebssysteme, auf denen LilyPond benutzt werden kann,
 283 unterstützen ein Programm mit dem Namen @code{make}.  Dieses Programm
 284 liest eine besondere Datei mit der Bezeichnung @code{Makefile},
 285 die definiert, welche Dateien von welchen anderen Dateien abhängen und
 286 welche Befehle für das Betriebssystem nötig sind, um eine Datei aus
 287 einer anderen zu erstellen. Ein Makefile könnte etwa erklären, wie
 288 @file{ballad.pdf} und @file{ballad.midi} aus @file{ballad.ly}
 289 erstellt werden können, indem LilyPond aufgerufen wird.
 290
 291 Es gibt Fällen, wenn es sich sehr stark empfiehlt, ein @code{Makefile}
 292 für das aktuelle Projekt zu erstellen, entweder zur eigenen Bequemlichkeit,
 293 oder aber auch als Hilfe für andere, die vielleicht einmal die
 294 Quelldateien lesen und verstehen wollen.  Insbesondere bei großen Projekten
 295 mit vielen eingefügten Dateien und unterschiedlichen Ausgabeoptionen
 296 (etwa Partitur, einzelne Stimmen, Dirigierpartitur, Klavierauszug usw.),
 297 aber auch bei Projekten, die komplizierte Programmaufrufe zur Verarbeitung
 298 erfordern (wenn man etwa mit @code{lilypond-book} arbeitet), lohnt
 299 sich die Erstellung einer Make-Datei.  Diese Dateien können sehr
 300 unterschiedliche ausfallen, und ihre Komplexität und Flexibilität kann
 301 den Bedürfnissen aber auch Kenntnissen des Schreibers angepasst werden.
 302 Das Programm GNU Make ist auf GNU/Linux Distributionen und MacOS X
 303 installiert, aber es ist auch für Windows erhältlich.
 304
 305 Das @strong{GNU Make Manual} gibt eine vollständige Anleitung, wie
 306 @code{make} benutzt werden kann.  Hier sollen nur einige kleine
 307 Blicke auf die vielfältigen Möglichkeiten geworfen werden.
 308
 309 Die Befehle, um Regeln in einer Make-Datei zu erstellen, unterscheidet
 310 sich zwischen den Betriebssystemen.  Die verschiedenen Linuxe und
 311 MacOS X benutzen @code{bash}, während unter Windows @code{cmd} eingesetzt
 312 wird.  Unter MacOS X muss man das System so konfigurieren, dass
 313 die Kommandozeile benutzt wird.  Hier einige Beispiele für Make-Dateien,
 314 mit Versionen für Linux/MacOS und Windows.
 315
 316 Das erste Beispiel ist für ein Orchesterstück in vier Stätzen unt mit
 317 der folgenden Dateistruktur:
 318
 319 @example
 320 Symphony/
 321 |-- MIDI/
 322 |-- Makefile
 323 |-- Notes/
 324 |   |-- cello.ily
 325 |   |-- figures.ily
 326 |   |-- horn.ily
 327 |   |-- oboe.ily
 328 |   |-- trioString.ily
 329 |   |-- viola.ily
 330 |   |-- violinOne.ily
 331 |   `-- violinTwo.ily
 332 |-- PDF/
 333 |-- Parts/
 334 |   |-- symphony-cello.ly
 335 |   |-- symphony-horn.ly
 336 |   |-- symphony-oboes.ly
 337 |   |-- symphony-viola.ly
 338 |   |-- symphony-violinOne.ly
 339 |   `-- symphony-violinTwo.ly
 340 |-- Scores/
 341 |   |-- symphony.ly
 342 |   |-- symphonyI.ly
 343 |   |-- symphonyII.ly
 344 |   |-- symphonyIII.ly
 345 |   `-- symphonyIV.ly
 346 `-- symphonyDefs.ily
 347 @end example
 348
 349 Die @file{.ly}-Dateien un den Verzeichnissen @file{Scores} und
 350 @file{Parts} erhalten ihrere Noten aus @file{.ily}-Dateien, die
 351 sich im @file{Notes}-Verzeichnis befinden:
 352
 353 @example
 354 %%% Kopfzeile der Datei "symphony-cello.ly"
 355 \include ../definitions.ily
 356 \include ../Notes/cello.ily
 357 @end example
 358
 359 Die Make-Datei hat die Ziele @code{score} (das gesamte Stück als
 360 große Partitur), @code{movements} (die einzelnen Sätze als große
 361 Partitur) und @code{parts} (die einzelnen Stimmen für die Spieler).
 362 Es gibt auch das Ziel @code{archive}, welches ein Tar-Archiv
 363 der Quelldateien erstellt, etwa um die Quellen über das Internet
 364 oder per E-Mail zu verteilen.  Hier die Make-Datei für GNU/Linux
 365 oder MacOS X.  Sie sollte unter dem Namen @code{Makefile} im obersten
 366 Verzeichnis des Projektes gespeichert werden:
 367
 368 @warning{Wenn ein Ziel oder eine Musterregel definiert ist, müssen
 369 die folgenden Zeilen mit Tabulatoren, nicht mit Leerzeichen beginnen.}
 370
 371 @example
 372 # Namensstamm der Ausgabedateien
 373 piece = symphony
 374 # finde heraus, wieviele Prozessoren vorhanden sind
 375 CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//`
 376 # Der Befehl, um lilypond aufzurufen
 377 LILY_CMD = lilypond -ddelete-intermediate-files \
 378                     -dno-point-and-click -djob-count=$(CPU_CORES)
 379
 380 # Die Endungen, die im Makefile benutzt werden
 381 .SUFFIXES: .ly .ily .pdf .midi
 382
 383 # Eingabe- und Ausgabedateien werden in den Verzeichnissen durchsucht,
 384 # die sich in der VPATH-Variable befinden.  Alle sind Unterverzeichnisse
 385 # des aktuellen Verzeichnisses (angegeben durch die GNU make-Variable
 386 # `CURDIR').
 387 VPATH = \
 388   $(CURDIR)/Scores \
 389   $(CURDIR)/PDF \
 390   $(CURDIR)/Parts \
 391   $(CURDIR)/Notes
 392
 393 # Die Musterregel, um PDF und MIDI-Dateien aus der LY-Eingabedatei
 394 # zu erstellen.  Die .pdf-Ausgabedateien werden in das
 395 # `PDF'-Unterverzeichnis abgelegt, die .midi-Dateien in das
 396 # `MIDI'-Unterverzeichnis.
 397 %.pdf %.midi: %.ly
 398         $(LILY_CMD) $<; \           # this line begins with a tab
 399         if test -f "$*.pdf"; then \
 400             mv "$*.pdf" PDF/; \
 401         fi; \
 402         if test -f "$*.midi"; then \
 403             mv "$*.midi" MIDI/; \
 404         fi
 405
 406 notes = \
 407   cello.ily \
 408   horn.ily \
 409   oboe.ily \
 410   viola.ily \
 411   violinOne.ily \
 412   violinTwo.ily
 413
 414 # Abhängigkeiten der einzelnen Sätze.
 415 $(piece)I.pdf: $(piece)I.ly $(notes)
 416 $(piece)II.pdf: $(piece)II.ly $(notes)
 417 $(piece)III.pdf: $(piece)III.ly $(notes)
 418 $(piece)IV.pdf: $(piece)IV.ly $(notes)
 419
 420 # Abhängigkeiten der großen Partitur.
 421 $(piece).pdf: $(piece).ly $(notes)
 422
 423 # Abhängigkeiten der Stimmen.
 424 $(piece)-cello.pdf: $(piece)-cello.ly cello.ily
 425 $(piece)-horn.pdf: $(piece)-horn.ly horn.ily
 426 $(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
 427 $(piece)-viola.pdf: $(piece)-viola.ly viola.ily
 428 $(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
 429 $(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
 430
 431 # `make score' eintippen, um die große Partitur mit allen vier
 432 # Sätzen als eine Datei zu erstellen.
 433 .PHONY: score
 434 score: $(piece).pdf
 435
 436 # `make parts' tippen, um alle Stimmen zu erstellen.
 437 # `make foo.pdf' tippen, um die Stimme für das Instrument `foo' zu erstellen.
 438 # Beispiel: `make symphony-cello.pdf'.
 439 .PHONY: parts
 440 parts: $(piece)-cello.pdf \
 441        $(piece)-violinOne.pdf \
 442        $(piece)-violinTwo.pdf \
 443        $(piece)-viola.pdf \
 444        $(piece)-oboes.pdf \
 445        $(piece)-horn.pdf
 446
 447 # `make movements' tippen um Dateien für die vier Sätze einzeln zu erstellen.
 448 .PHONY: movements
 449 movements: $(piece)I.pdf \
 450            $(piece)II.pdf \
 451            $(piece)III.pdf \
 452            $(piece)IV.pdf
 453
 454 all: score parts movements
 455
 456 archive:
 457         tar -cvvf stamitz.tar \       # this line begins with a tab
 458         --exclude=*pdf --exclude=*~ \
 459         --exclude=*midi --exclude=*.tar \
 460         ../Stamitz/*
 461 @end example
 462
 463 Unter Windows ergeben sich bestimmte Komplikationen.  Nachdem man
 464 GNU Make für Windows heruntergeladen und installiert hat, muss
 465 man den richtigen Pfad in den Umgebungsvariablen des Systems setzen,
 466 damit die DOS-Kommandozeile das Make-Programm finden kann.  Um das
 467 vorzunehmen, kann mit der rechten Maustaste auf "Arbeitsplatz"
 468 klicken, dann @code{Eigenschaften} und @code{Erweitert} geklickt
 469 werden.  Hier wählt man @code{Umgebungsvariablen}.  In der
 470 Liste @code{Systemvariablen} wählt man @code{Path} und mit
 471 einem Klick auf @code{Bearbeiten} kann man den Pfad zu der
 472 @code{.exe}-Datei von GNU Make hinzufügen, der etwa wie
 473 folgt aussieht:
 474
 475 @example
 476 C:\Program Files\GnuWin32\bin
 477 @end example
 478
 479 Die Make-Datei selber muss auch angepasst werden, um unterschiedliche
 480 Shell-Befehle zu verwenden und mit Leerzeichen umgehen zu können,
 481 die sich in einigen Standardverzeichnissen unter Windows befinden.
 482 Das @code{archive}-Ziel wird entfernt, da Windows den
 483 @code{tar}-Befehl nicht kennt, und Windows benutzt auch eine
 484 andere Dateiendung für midi-Dateien.
 485
 486
 487 @example
 488 ## WINDOWS VERSION
 489 ##
 490 piece = symphony
 491 LILY_CMD = lilypond -ddelete-intermediate-files \
 492                     -dno-point-and-click \
 493                     -djob-count=$(NUMBER_OF_PROCESSORS)
 494
 495 # 8.3 Bezeichnung für CURDIR erhalten (Workaround wg. Leerzeichen in PATH)
 496 workdir = $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \
 497           do @@echo %%~sb)
 498
 499 .SUFFIXES: .ly .ily .pdf .mid
 500
 501 VPATH = \
 502   $(workdir)/Scores \
 503   $(workdir)/PDF \
 504   $(workdir)/Parts \
 505   $(workdir)/Notes
 506
 507 %.pdf %.mid: %.ly
 508         $(LILY_CMD) $<      # diese Zeile beginnt mit Tabulator
 509         if exist "$*.pdf"  move /Y "$*.pdf"  PDF/ # begin with tab
 510         if exist "$*.mid" move /Y "$*.mid" MIDI/  # begin with tab
 511
 512 notes = \
 513   cello.ily \
 514   figures.ily \
 515   horn.ily \
 516   oboe.ily \
 517   trioString.ily \
 518   viola.ily \
 519   violinOne.ily \
 520   violinTwo.ily
 521
 522 $(piece)I.pdf: $(piece)I.ly $(notes)
 523 $(piece)II.pdf: $(piece)II.ly $(notes)
 524 $(piece)III.pdf: $(piece)III.ly $(notes)
 525 $(piece)IV.pdf: $(piece)IV.ly $(notes)
 526
 527 $(piece).pdf: $(piece).ly $(notes)
 528
 529 $(piece)-cello.pdf: $(piece)-cello.ly cello.ily
 530 $(piece)-horn.pdf: $(piece)-horn.ly horn.ily
 531 $(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
 532 $(piece)-viola.pdf: $(piece)-viola.ly viola.ily
 533 $(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
 534 $(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
 535
 536 .PHONY: score
 537 score: $(piece).pdf
 538
 539 .PHONY: parts
 540 parts: $(piece)-cello.pdf \
 541        $(piece)-violinOne.pdf \
 542        $(piece)-violinTwo.pdf \
 543        $(piece)-viola.pdf \
 544        $(piece)-oboes.pdf \
 545        $(piece)-horn.pdf
 546
 547 .PHONY: movements
 548 movements: $(piece)I.pdf \
 549            $(piece)II.pdf \
 550            $(piece)III.pdf \
 551            $(piece)IV.pdf
 552
 553 all: score parts movements
 554 @end example
 555
 556 Die nächste Make-Datei ist für ein @command{lilypond-book}-Dokument,
 557 das in LaTeX gesetzt wird.  Das Projekt hat einen Index, welcher
 558 erfordert, dass der Befehl @command{latex} zweimal aufgerufen wird,
 559 um die Verweise zu aktualisieren.  Ausgabedateien werden in einem
 560 @code{out}-Verzeichnis für die .pdf-Dateien gespeichert und in
 561 @code{htmlout} für die html-Dateien.
 562
 563 @example
 564 SHELL=/bin/sh
 565 FILE=myproject
 566 OUTDIR=out
 567 WEBDIR=htmlout
 568 VIEWER=acroread
 569 BROWSER=firefox
 570 LILYBOOK_PDF=lilypond-book --output=$(OUTDIR) --pdf $(FILE).lytex
 571 LILYBOOK_HTML=lilypond-book --output=$(WEBDIR) $(FILE).lytex
 572 PDF=cd $(OUTDIR) && pdflatex $(FILE)
 573 HTML=cd $(WEBDIR) && latex2html $(FILE)
 574 INDEX=cd $(OUTDIR) && makeindex $(FILE)
 575 PREVIEW=$(VIEWER) $(OUTDIR)/$(FILE).pdf &
 576
 577 all: pdf web keep
 578
 579 pdf:
 580         $(LILYBOOK_PDF)  # begin with tab
 581         $(PDF)           # begin with tab
 582         $(INDEX)         # begin with tab
 583         $(PDF)           # begin with tab
 584         $(PREVIEW)       # begin with tab
 585
 586 web:
 587         $(LILYBOOK_HTML) # begin with tab
 588         $(HTML)          # begin with tab
 589         cp -R $(WEBDIR)/$(FILE)/ ./  # begin with tab
 590         $(BROWSER) $(FILE)/$(FILE).html &  # begin with tab
 591
 592 keep: pdf
 593         cp $(OUTDIR)/$(FILE).pdf $(FILE).pdf  # begin with tab
 594
 595 clean:
 596         rm -rf $(OUTDIR) # begin with tab
 597
 598 web-clean:
 599         rm -rf $(WEBDIR) # begin with tab
 600
 601 archive:
 602         tar -cvvf myproject.tar \ # begin this line with tab
 603         --exclude=out/* \
 604         --exclude=htmlout/* \
 605         --exclude=myproject/* \
 606         --exclude=*midi \
 607         --exclude=*pdf \
 608         --exclude=*~ \
 609         ../MyProject/*
 610 @end example
 611
 612 TODO: soll auch unter Windows funktionieren
 613
 614 Die vorige Make-Datei funktioniert nicht unter Windows.  Als Alternative
 615 für Windows-Benutzer könnte man eine einfache batch-Datei erstellen,
 616 welche die erforderlichen Befehl enthält.  Sie kümmert sich nicht
 617 um Abhängigkeiten, wie es eine Make-Datei kann, aber wenigstens
 618 wird die Kompilation auf einen einzigen Befehl beschränkt.  Das folgende
 619 kann als Datei @command{build.bat} oder @command{build.cmd} gespeichert
 620 werden.  Die Batch-Datei kann auf der Kommandozeile aufgerufen werden
 621 oder einfach doppelt angeklickt werden.
 622
 623 @example
 624 lilypond-book --output=out --pdf myproject.lytex
 625 cd out
 626 pdflatex myproject
 627 makeindex myproject
 628 pdflatex myproject
 629 cd ..
 630 copy out\myproject.pdf MyProject.pdf
 631 @end example
 632
 633
 634 @seealso
 635 Programmbenutzung:
 636 @rprogram{Benutzung auf der Kommandozeile},
 637 @rprogram{lilypond-book}.
 638