Ein Mitarbeiter von Red Hat stellte das Build-System Goals vor. Veröffentlichung von GNU Make 4.2.

Richard Jones, Autor libguestfs, tätig bei Red Hat, den ein neues Build-Tool Ziele, das darauf abzielt, Mängel und Probleme des make-Tools zu beheben, während die allgemeine Einfachheit und Verständlichkeit der Skripte erhalten bleibt. Das make-Tool wurde 1976 konzipiert und weist mehrere konzeptionelle Schwächen auf, die mit Goals behoben werden sollen, ohne das grundlegende Konzept zu verändern.
Quellcode von Goals wird unter der GPLv3-Lizenz bereitgestellt. steht 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 Ziel-Datei fehlt oder älter ist als eine der Abhängigkeiten.' In Goals ist geplant, auch andere Taktiken umzusetzen, wie zum Beispiel die Überprüfung der URL, den Vergleich des Änderungszeitpunkts mit irgendeiner Datei, die Bewertung des Paket-Baus in Koji, den Vergleich von Prüfziffern, die Ausführung von Test-Suiten mit selektivem Testauslass.
• Bei der Verarbeitung von Build-Zielen trennt das Tool make keine Dateien und Regelnamen, was zur Folge hat, dass nicht überprüft wird, ob beim Ausführen der Regel tatsächlich eine Datei erstellt wird, deren Erstellung sie behauptet. Wenn beispielsweise 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, das Ziel sei bereits erreicht und erfordere keine weiteren Aktionen (um das Problem zu umgehen, kann in make die Direktive „.PHONY: test“ angegeben werden). Goals trennt explizit Dateien und Regelnamen.
  
• Probleme bei der Bereitstellung nur eines Parameters für Build-Anweisungen.
  

  In Goals wird vorgeschlagen, eine beliebige Anzahl benannter Parameter zu verwenden. Zum Beispiel kann das Merkmal einer Debug-Datei separat aus dem Namen herausgefiltert werden:

  
• Interaktionsprobleme mit dem Shell-Interpreter. Beispielsweise die Notwendigkeit, die Escape-Zeichen für Leerzeichen in Datei- und Verzeichnisnamen zu kontrollieren, der Ressourceneinsatz durch das Starten eines separaten Shell-Interpreters für die Ausführung jedes Befehls, die doppelte Interpretation des Zeichens „$“ (das sowohl in der Shell als auch in make verwendet wird) und die Berücksichtigung von Einrückungen.

  Die angegebenen Probleme werden in Goals gelöst, indem das Symbol „%“ anstelle von „$“ für Build-Variablen verwendet wird („$“ bleibt nur für die Shell), durch die Anwendung eines Parsers. LALR(1), das erfordert, dass Pfade und Dateinamen in Anführungszeichen gesetzt und Codeblöcke in geschweifte Klammern eingeschlossen werden. Der gesamte Block wird in einer Instanz der Kommandozeile ausgeführt, und innerhalb des Blocks ist beliebige Formatierung des Codes erlaubt, ohne an spezielle Leerzeichen gebunden zu sein.

  War:
  target: foo.o bar.o
  ${CC} ${CFLAGS} $< -o $@

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

Weitere Besonderheiten von Goals:

• Optionale Unterstützung zur Festlegung 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 zum Zuordnen von Build-Zielen zu Dateinamen (z. B. die Datei „foo.o“ entspricht dem Ziel „%name.o“) und der Modus für den direkten Kompilierungstart:

  goal all = : link

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

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

• Die Taktik der Erstellung wird durch spezielle Regeln definiert, mit deren Hilfe die Notwendigkeit einer Neu-Assembly des Zielobjekts festgestellt werden kann. Wenn eine Verknüpfung zur Verfügbarkeit einer Datei erfolgt, wird dies eindeutig durch das entsprechende Merkmal bestimmt ("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") { … }

• Der Entwickler kann beliebige Merkmale für die Erstellungsstrategien definieren. Das Merkmal "*file" ist standardmäßig definiert (@{…} zeigt die Ausgabeunterdrückung an, und "exit 99" signalisiert die Notwendigkeit einer Neu-Assembly):

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

  Quelle: opennet.ru