Richard Jones (Richard WM Jones), szerző , a Red Hat munkatársa, új build eszközként , amely a make eszköz hibáinak és problémáinak kijavítására irányul, miközben megőrzi a szkriptek általános egyszerűségét és érthetőségét. A make eszközt 1976-ban tervezték meg, és számos koncepcionális hiányossággal rendelkezik, amelyeket a Goals célként kíván orvosolni az alapvető koncepció megváltoztatása nélkül.
A Goals forráskódja GPLv2+ licenc alatt.
:
- Csak egy függőség-megoldási technika támogatása — „a build utasítást akkor indítják el, ha a célfájl hiányzik, vagy régebbi, mint bármelyik függőség”. A Goals tervezi más technikák megvalósítását is, mint például egy URL meglétének ellenőrzése, a fájlok módosítási idejének összehasonlítása bármely fájllal, a csomag build idejének értékelése a , ellenőrző összeg összehasonlítása, a tesztkészletek végrehajtása, szelektív tesztkihagyással.
- A build célok feldolgozása során a make eszköz nem választja szét a fájlokat és a szabályok neveit, és ennek következtében hiányzik annak ellenőrzése, hogy a szabály végrehajtásának indításakor valóban létrejön-e az a fájl, amelyről kijelentették. Például, ha van egy „test” nevű szabály, amely tesztelők futtatására szolgál, és véletlenül egy „test” nevű fájl jön létre, akkor a tesztek nem fognak lefutni, mivel a make úgy véli, hogy a cél már elkészült és nem igényel további lépéseket (a probléma kikerülésére a make-ben a „.PHONY: test” direktíva megadható). A Goals világosan elválasztja a fájlokat és a szabályok neveit.
- A build utasításokhoz csak egy paraméter megadásának problémája.
A Goals lehetővé teszi tetszőleges számú név szerinti paraméter használatát. Például külön kiemelheti a névből a hibakeresési fájl jelét:
- A shell-értelmezővel való interakció problémái. Például, szükséges az üres helyek kódolásának ellenőrzése a fájlok és könyvtárak neveiben, erőforrások felhasználása minden parancs végrehajtásakor egy külön shell-értelmező indítására, a „$” karakter kettős értelmezésének figyelembevétele (a shell-ben és a make-ben is használják), a behúzások figyelembevétele.
A megadott problémák a Goals-ban a „%” jel használatával oldódnak meg a build változókhoz („$” csak a shell esetében marad), a parszert alkalmazva , amely megköveteli, hogy az útvonalakat és a fájlneveket idézőjelek közé zárjuk, és a kódblokkokat kapcsos zárójelek közé helyezzük. Az egész blokk egy példányban fut el a parancssorban, és a blokkban tetszőleges kódformázás engedélyezett, különleges szóközök nélkül.
Régebben:
cél: foo.o bar.o
${CC} ${CFLAGS} $< -o $@Most:
«cél»: «foo.o», «bar.o» {
LAGS < -o %@
}
A Goals egyéb jellemzői:
- Opcionális támogatás véletlenszerű nevekből és paraméterekből:
cél all = : «cél»
cél link =
«cél» : «foo.o», «bar.o» { … }cél fordítás (név) =
«%name.o» : «%name.c», «dep.h» { LAGS -c $^ -o $@ } - Két indítási mód: make üzemmód a build-célok és fájlnevek összepárosításához (például a «foo.o» fájl megfelel a «%name.o» célnak), és közvetlen fordítási üzemmód:
cél all = : link
cél link =
«cél» : «foo.o», fordítás («bar») { … }cél fordítás (név) =
«%name.o» : «%name.c», «dep.h» { LAGS -c $^ -o $@ } - A build taktikát speciális szabályok határozzák meg, amelyeken keresztül meghatározható a build cél újrafordításának szükségessége. Ha a fájl meglétéhez kötődünk, azt egyértelműen meg kell határozni a megfelelő jelzőn keresztül («cél» a szabály neve és *file(«cél») a fájl ellenőrzéséhez).
«cél» : «foo.o», «bar.o» { … }
*file(«cél») : *file(«foo.o»), *file(«bar.o») { … }
- A fejlesztő véletlenszerű build taktikákat definiálhat. A «*file» jelző alapértelmezés szerint definiált (@{…} a kimenet elnyomására utal, míg az «exit 99» jelez egy újrafordítási szükségletet):
taktika *file (fájlnév) = @{
test -f %filename || exit 99
for f in %Forrás: opennet.ru
