Projektdatei *.lpf — ein Bau, eine Datei

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

lyxc projekt.lpf

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

→ Tools & Compiler · Compiler-Parameter · LPM — Package Manager

1. Aufbau

[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

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:

bad.lpf:1: unbekannter Abschnitt [incldue]. Bekannt: [projekt] [include] [schalter] [pakete].

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

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.

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 (#1724).

4. Ein vollständiges Beispiel

mkdir -p build
lyxc demo.lpf && ./build/demo

[projekt]
quelle  = "t.lyx"
ziel    = "linux"
ausgabe = "build/demo"

[include]
pfade = ["."]

[schalter]
liste = ["-O2"]

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).