====== Projektdatei *.lpf — ein Bau, eine Datei ======

Statt Quelle, Ziel, Include-Pfade und Schalter bei jedem Aufruf zu wiederholen, stehen sie in einer Datei:

<code bash>
lyxc projekt.lpf
</code>

Das Format ist eine **kleine TOML-Teilmenge**; deutsche und englische Schlüssel sind gleichwertig. Seit lyxc 1.1.13A.

→ [[lyx_-_programmiersprache:tools|Tools & Compiler]] · [[lyx_-_programmiersprache:tools:compiler-parameter|Compiler-Parameter]] · [[lyx_-_programmiersprache:tools:lpm|LPM — Package Manager]]

----

===== 1. Aufbau =====

<code toml>
[projekt]
quelle  = "apps/vcldemo.lyx"       # Pflicht
ziel    = "lyxos"                  # wie --target=
ausgabe = "build/vcldemo.lbf"      # wie -o

[include]
pfade = [".", "platform/lyxos"]

[schalter]
liste = ["--emit=lbf", "-O2"]

[pakete]
vega = "0.3.1"                     # via `lpm resolve` aufgelöst
</code>

^ Abschnitt ^ Schlüssel ^ Entspricht ^
| ''[projekt]'' | ''quelle'' (Pflicht), ''ziel'', ''ausgabe'' | die Quelldatei, ''%%--%%target='', ''-o'' |
| ''[include]'' | ''pfade'' (Liste) | je ein ''-I'' |
| ''[schalter]'' | ''liste'' (Liste) | beliebige Schalter der Kommandozeile |
| ''[pakete]'' | ''<name> = "<version>"'' | wird über ''lpm resolve <name> <version>'' aufgelöst |

===== 2. Die vier Regeln, die man kennen muss =====

  * **Die Kommandozeile überstimmt die Datei.** ''lyxc demo.lpf --target=linux'' ist ein Gegenversuch, ohne die Datei anzufassen. Nachgemessen: ''lyxc demo.lpf --target=lyxos -o build/demo.lbf'' erzeugt einen LBF-Container (''LYX!''), obwohl in der Datei ''ziel = "linux"'' steht.
  * **Relative Pfade zählen vom Verzeichnis der ''.lpf''**, nicht vom Arbeitsverzeichnis. Dieselbe Datei baut damit von überall dasselbe — nachgemessen aus dem Elternverzeichnis heraus, gleiches Erzeugnis.
  * **Schalter laufen durch denselben Parser wie die Kommandozeile.** Es gibt keine zweite, veraltende Schaltertabelle.
  * **Unbekannte Abschnitte und Schlüssel werden gemeldet**, nicht übergangen:

<code>
bad.lpf:1: unbekannter Abschnitt [incldue]. Bekannt: [projekt] [include] [schalter] [pakete].
</code>

> Ein Tippfehler ''[incldue]'' verschlänge sonst alle Pfade darin und fiele erst weit später als „Modul nicht gefunden" auf.

<box gh>
> **Das Ausgabeverzeichnis legt lyxc nicht an.** Steht ''ausgabe = "build/demo"'' und es gibt kein ''build/'', endet der Lauf mit ''error: codegen: Ausgabedatei laesst sich nicht oeffnen: build/demo''. Ein ''mkdir -p build'' gehört ins Bauskript.
</box>

===== 3. Pakete — der erste Aufruf von lpm durch den Compiler =====

Mit ''[pakete]'' ruft **der Compiler selbst** den Paketmanager: ''lpm resolve <name> <version>''. Entwickelt wird ''lpm'' im eigenständigen Projekt ''SEOLizer/lyx-lpm''; ''lyxc'' hängt nur am **Programm**, nicht an dessen Quelltext.

Ein Paket liegt im Cache flach (''~/.lpm/cache/vega/0.3.1/types.lyx''), während seine Unit ''vega.types'' heißt. Die Zuordnung erfolgt deshalb über den **Paketnamen**, nicht über einen Include-Pfad — und steht in ''src/paket_pfade.lyx'' **einmal**, benutzt von beiden Auflösern (''sema'' und ''ir_lower''), die dieselbe Antwort geben müssen ([[https://github.com/SEOLizer/LyX-Compiler/issues/1724|#1724]]).

===== 4. Ein vollständiges Beispiel =====

<code bash>
mkdir -p build
lyxc demo.lpf && ./build/demo
</code>

<code toml>
[projekt]
quelle  = "t.lyx"
ziel    = "linux"
ausgabe = "build/demo"

[include]
pfade = ["."]

[schalter]
liste = ["-O2"]
</code>

----

Letzte Aktualisierung: 2026-08-30 — Seite neu angelegt; gegen lyxc 1.1.14A gemessen (Bau, Überstimmen durch die Kommandozeile, Lauf aus einem anderen Verzeichnis, Meldung bei falschem Abschnittsnamen, fehlendes Ausgabeverzeichnis).