Richard Jones, Autor , tätig bei Red Hat, ein neues Build-Tool , 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 steht unter der GPLv2+ Lizenz.
:
- 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 , 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.
Указанные проблемы решаются в Goals использованием символа «%» вместо «$» для сборочных переменных («$» остаётся только для shell), применением парсера , требующего обрамлять пути и имена файлов кавычками и выделять фигурными скобками блоки с кодом. Весь блок команда запускается в одном экземпляре командной оболочки, а внутри блока допускается произвольное форматирование кода, без привязки к специальным пробелам.
War:
target: foo.o bar.o
${CC} ${CFLAGS} $< -o $@Ist geworden:
«target»: «foo.o», «bar.o» {
%CC %CFLAGS %< -o %@
}
Другие особенности Goals:
- Опциональная поддержка задания произвольных имён и параметров:
goal all = : «target»
goal link =
«target» : «foo.o», «bar.o» { … }goal compile (name) =
«%name.o» : «%name.c», «dep.h» { %CC %CFLAGS -c $^ -o $@ } - Два режима запуска: режим make для сопоставления сборочных целей с именами файлов (например, файл «foo.o» соответствует цели «%name.o»), и режим прямого запуска компиляции:
goal all = : link
goal link =
«target» : «foo.o», compile («bar») { … }goal compile (name) =
«%name.o» : «%name.c», «dep.h» { %CC %CFLAGS -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
