Stil-Empfehlungen

Diese Seite listet einige Empfehlungen für die Organisation und Formatierung Ihrer Meson-Build-Dateien auf.

Tabs oder Leerzeichen?

Immer Leerzeichen. Zwei Leerzeichen sind am gebräuchlichsten.

Nachgestellte Kommas?

Ja, wo möglich. Sie helfen, schönere Diffs in Versionskontrollsystemen zu erzeugen.

Variablennamen

Snake Case (stilisiert als snake_case) bezieht sich auf den Schreibstil, bei dem jedes Leerzeichen durch einen Unterstrich (_) ersetzt wird und der erste Buchstabe jedes Wortes klein geschrieben wird. Es ist die gebräuchlichste Namenskonvention, die in Meson-Build-Skripten als Bezeichner für Variablen verwendet wird.

Nehmen wir an, Sie möchten Ihre ausführbare Datei als my_exe bezeichnen.

Abhängigkeitsnutzung

Die Funktion dependency ist die empfohlene Methode zur Verwaltung von Abhängigkeiten. Wenn Ihre Wrap-Dateien die notwendigen [provide]-Einträge enthalten, funktioniert alles automatisch, sowohl beim Kompilieren Ihrer eigenen als auch bei der Verwendung von Systemabhängigkeiten.

Sie benötigen subproject nur, wenn Sie etwas anderes als Abhängigkeiten/Programme extrahieren müssen.

Optionsnamen

Es gibt zwei Möglichkeiten, Projektoptionen zu benennen. Als Beispiel für Booleans ist der erste Stil foo und der zweite Stil enable-foo. Der erstere Stil wird empfohlen, da Meson-Optionen starke Typen haben und nicht nur Zeichenketten sind.

Sie sollten versuchen, Optionen so zu benennen, wie es in anderen Projekten üblich ist. Dies ist besonders wichtig für Yielding-Optionen, da diese erfordern, dass sowohl die übergeordneten als auch die untergeordneten Projektoptionen denselben Namen haben.

Globale Argumente

Bevorzugen Sie add_project_arguments gegenüber add_global_arguments, da die Verwendung letzterer die Verwendung des Projekts als Subprojekt verhindert.

Cross-Kompilierungsargumente

Versuchen Sie, Cross-Kompilierungsargumente so weit wie möglich aus Ihren Build-Dateien fernzuhalten. Bewahren Sie sie stattdessen in der Cross-Datei auf. Dies erhöht die Portabilität, da alle Änderungen, die für die Kompilierung auf eine andere Plattform erforderlich sind, an einem Ort isoliert sind.

Sortieren von Quellpfaden

Die Quellcodedatei-Arrays sollten alle sortiert sein. Dies erleichtert das Erkennen von Fehlern und reduziert oft Merge-Konflikte. Darüber hinaus sollten die Pfade mit einem natürlichen Sortieralgorithmus sortiert werden, so dass Zahlen intuitiv sortiert werden (1, 2, 3, 10, 20 anstelle von 1, 10, 2, 20, 3).

Zahlen sollten auch vor Zeichen sortiert werden (a111 vor ab0). Darüber hinaus sollten Zeichenketten case-insensitiv sortiert werden.

Zusätzlich gilt: Wenn ein Pfad ein Verzeichnis enthält, sollte er vor normalen Dateien sortiert werden. Diese Regel gilt auch rekursiv für Unterverzeichnisse.

Das folgende Beispiel zeigt eine korrekte Definition der Quellcode-Liste

sources = files(
  'aaa/a1.c',
  'aaa/a2.c',
  'bbb/subdir1/b1.c',
  'bbb/subdir2/b2.c',
  'bbb/subdir10/b3.c',
  'bbb/subdir20/b4.c',
  'bbb/b5.c',
  'bbb/b6.c',
  'f1.c',
  'f2.c',
  'f10.c',
  'f20.c',
)