Richard Jones (Richard WM Jones), autore , che lavora per Red Hat, nuovo strumento di assemblaggio , mirato a risolvere le carenze e i problemi dello strumento make mantenendo la semplicità e la chiarezza degli script. Lo strumento make è stato progettato nel 1976 e presenta varie lacune concettuali; Goals si propone di affrontarle senza modificare il concetto generale.
Codice sorgente di Goals sotto licenza GPLv2+.
:
- Support for only one dependency resolution tactic — "the build instruction is executed if the target file is missing or older than one of the dependencies." Other tactics are planned for Goals, such as checking the presence of a URL, comparing modification times with any file, evaluating package builds in , il confronto dei checksum, l'esecuzione di suite di test con passaggi selettivi dei test.
- When processing build goals, the make utility does not distinguish between files and rule names, and as a consequence, there is no check that the rule will actually create the file it claims to create when executed. For example, if a rule named "test" that runs testing scripts inadvertently creates a file named "test", the tests will stop being called, as make will assume the goal is built and does not require any actions (to bypass this issue in make, the directive ".PHONY: test" can be specified). Goals explicitly separates files and rule names.

- Problema di fornire solo un parametro per le istruzioni di assemblaggio.

In Goals si propone di utilizzare un numero arbitrario di parametri con nome. Ad esempio, è possibile estrarre separatamente il flag del file di debug dal nome:

- Issues interacting with the shell interpreter. For example, the need to control space escaping in file and directory names, the resource expense of launching a separate shell interpreter for each command execution, double interpretation of the symbol "$" (which is used both in shell and in make), accounting for indentation.
The stated issues are resolved in Goals by using the symbol "%" instead of "$" for build variables ("$" remains only for shell), applying a parser , richiedendo di racchiudere percorsi e nomi di file tra virgolette e di delimitare i blocchi di codice con parentesi graffe. L'intero blocco di comandi viene eseguito in un'unica istanza della shell, e all'interno del blocco è consentito un formattazione arbitraria del codice, senza dipendere da spazi speciali.
Era:
target: foo.o bar.o
${CC} ${CFLAGS} $< -o $@Risultato:
"target": "foo.o", "bar.o" {
LAGS < -o %@
}
Altre caratteristiche di Goals:
- Supporto opzionale per la definizione di nomi e parametri arbitrari:
goal all = : "target"
goal link =
"target": "foo.o", "bar.o" { … }goal compile (name) =
«%name.o» : «%name.c», «dep.h» { LAGS -c $^ -o $@ } - Two modes of execution: make mode for matching build goals with file names (for example, the file "foo.o" corresponds to the goal "%name.o"), and the direct compilation launch mode:
goal all = : link
goal link =
"target": "foo.o", compile ("bar") { … }goal compile (name) =
«%name.o» : «%name.c», «dep.h» { LAGS -c $^ -o $@ } - The build tactic is defined by special rules that allow determining the necessity of rebuilding the build goal. If it is bound to the presence of a file, this is explicitly defined through the corresponding attribute ("target" for the rule name and *file("target") for the file check).
"target": "foo.o", "bar.o" { … }
*file("target"): *file("foo.o"), *file("bar.o") { … }
- The developer can define arbitrary attributes for build tactics. The attribute "*file" is defined by default (@{…} indicates output suppression, and "exit 99" signals the need for rebuilding):
tactic *file (filename) = @{
test -f %filename || exit 99
for f in %Fonte: opennet.ru



