Ein Mitarbeiter von Red Hat präsentierte das Build-System Goals. Veröffentlichung von GNU Make 4.2

Richard Jones (Richard WM Jones), Autor libguestfs, der bei Red Hat arbeitet, vor ein neues Build-Tool Ziele, das darauf abzielt, Mängel und Probleme im make-Tool zu beheben und gleichzeitig die gesamte Einfachheit und Verständlichkeit der Skripte zu bewahren. Das make-Tool wurde 1976 konzipiert und weist eine Reihe konzeptioneller Mängel auf, die in den Zielen behoben werden sollen, ohne das Gesamtkonzept zu ändern.
Quellcode der Ziele wird verbreitet unter der GPLv2+-Lizenz.

Zu lösende Probleme:

• Unterstützung nur einer Taktik zur Auflösung von Abhängigkeiten – "Die Build-Anweisung wird ausgeführt, wenn die Zieldatei fehlt oder älter als eine der Abhängigkeiten ist." In den Zielen soll auch die Implementierung anderer Taktiken erfolgen, wie z. B. die Überprüfung der Verfügbarkeit von URLs, der Vergleich des Änderungszeitpunkts mit einer beliebigen Datei, die Bewertung des Paketbaus in Koji, der Vergleich von Prüfziffern, das Ausführen von Test-Suites mit selektivem Überspringen von Tests.
• Bei der Bearbeitung von Build-Zielen trennt das make-Tool keine Dateien von Regelbezeichnungen, was dazu führt, dass keine Überprüfung stattfindet, dass beim Ausführen einer Regel tatsächlich die angegebene Datei erstellt wird. Beispielsweise, wenn bei einer Regel mit dem Namen "test", die Skripte mit Tests ausführt, zufällig eine Datei mit dem Namen "test" erstellt wird, werden die Tests nicht mehr aufgerufen, da make annimmt, dass das Ziel abgeschlossen ist und keine weiteren Aktionen erforderlich sind (um dieses Problem in make zu umgehen, kann die Direktive ".PHONY: test" angegeben werden). Die Ziele unterscheiden deutlich zwischen Dateien und Regelbezeichnungen.
  
• Das Problem, nur einen Parameter für die Build-Anweisungen bereitzustellen.
  

  In den Zielen wird vorgeschlagen, eine beliebige Anzahl benannter Parameter zu verwenden. Beispielsweise kann man das Merkmal der Debugging-Datei aus dem Namen separat herausheben:

  
• Probleme bei der Interaktion mit dem Shell-Interpreter. Zum Beispiel die Notwendigkeit, die Escape-Sequenzen für Leerzeichen in Dateinamen und Verzeichnissen zu kontrollieren, der Ressourcenaufwand für das Starten eines separaten Shell-Interpreters bei der Ausführung jedes Befehls, die doppelte Interpretation des Symbols "$" (das sowohl in der Shell als auch in make verwendet wird), die Berücksichtigung von Einrückungen.

  Die genannten Probleme werden in den Zielen durch die Verwendung des Symbols "%" anstelle von "$" für Build-Variablen gelöst ("$" bleibt nur für die Shell), durch die Anwendung des Parsers LALR(1), die Pfade und Dateinamen in Anführungszeichen setzen und Codeblöcke in geschweifte Klammern einschließen müssen. Der gesamte Block wird in einem einzigen Instanz der Kommandozeile ausgeführt, und innerhalb des Blocks ist beliebige Codeformatierung zulässig, ohne an spezielle Leerzeichen gebunden zu sein.

  Früher:
  target: foo.o bar.o
  ${CC} ${CFLAGS} <$ -o $@

  Ist geworden:
  „target“: „foo.o“, „bar.o“ {
  LAGS < -o %@
  }

Weitere Merkmale von Goals:

• Optionale Unterstützung für die Angabe beliebiger Namen und Parameter:

  goal all = : „target“

  goal link =
  „target“ : „foo.o“, „bar.o“ { … }

  goal compile (name) =
  «%name.o» : «%name.c», «dep.h» { LAGS -c $^ -o $@ }

• Zwei Ausführungsmodi: Der Make-Modus zur Zuordnung von Build-Zielen zu Dateinamen (zum Beispiel entspricht die Datei „foo.o“ dem Ziel „%name.o“), und der Modus für direkte Kompilierung:

  goal all = : link

  goal link =
  „target“ : „foo.o“, compile („bar“) { … }

  goal compile (name) =
  «%name.o» : «%name.c», «dep.h» { LAGS -c $^ -o $@ }

• Die Build-Taktik wird durch spezielle Regeln definiert, die festlegen, wann ein Build-Ziel neu kompiliert werden muss. Wenn eine Bindung an das Vorhandensein einer Datei besteht, wird dies eindeutig über das entsprechende Kennzeichen definiert („target“ für den Namen der Regel und *file(„target“) zur Überprüfung der Datei).

  „target“ : „foo.o“, „bar.o“ { … }

  *file(„target“) : *file(„foo.o“), *file(„bar.o“) { … }

• Entwickler können beliebige Kennzeichen für Build-Taktiken definieren. Das Kennzeichen „*file“ ist standardmäßig definiert (@{…} zeigt die Unterdrückung der Ausgabe an, und „exit 99“ signalisiert die Notwendigkeit einer Neubaukompilierung):

  tactic *file (filename) = @{
  test -f %filename || exit 99
  for f in %

  Quelle: opennet.ru