Richard Jones (Richard WM Jones), autor , pracujący w firmie Red Hat, nowe narzędzie do budowania , którego celem jest usunięcie wad i problemów w narzędziu make przy zachowaniu ogólnej prostoty i zrozumiałości skryptów. Narzędzie make zostało zaprojektowane w 1976 roku i ma szereg koncepcyjnych niedoróbek, które w Cele planuje się usunąć, nie zmieniając ogólnej koncepcji.
Kod źródłowy Celów na licencji GPLv2+.
:
- Wsparcie tylko jednej taktyki rozwiązywania zależności — „instrukcja budowlana jest uruchamiana, jeśli plik docelowy nie istnieje lub jest starszy niż jedna z zależności”. W Cele planuje się wdrożenie innych taktyk, takich jak sprawdzanie dostępności URL, porównywanie czasu modyfikacji z dowolnym plikiem, ocena budowy pakietu w , porównywanie sum kontrolnych, uruchamianie zestawów testowych z selektywnym pomijaniem testów.
- Podczas przetwarzania celów budowania narzędzie make nie rozdziela plików i nazw reguł, a w konsekwencji brak jest weryfikacji, że przy uruchomieniu reguły rzeczywiście zostanie utworzony plik, którego utworzenie jest zadeklarowane. Na przykład, jeśli przy istnieniu reguły o nazwie „test”, uruchamiającej skrypty z testami, przypadkowo zostanie utworzony plik o nazwie „test”, testy przestaną być wywoływane, ponieważ make uzna, że cel został zbudowany i nie wymaga wykonywania jakichkolwiek działań (aby obejść problem w make, można wskazać dyrektywę „.PHONY: test”). Cele wyraźnie rozdzielają pliki i nazwy reguł.
- Problem z podawaniem tylko jednego parametru dla poleceń budowlanych.
W Cele zaproponowano użycie dowolnej liczby nazwanych parametrów. Na przykład, można oddzielić z nazwy cechę pliku debugowania:
- Problemy z interakcją z interpreterem shell. Na przykład, potrzeba kontrolowania eskapowania spacji w nazwach plików i katalogach, marnowanie zasobów na uruchamianie oddzielnego interpretera shell przy wykonywaniu każdej komendy, podwójna interpretacja symbolu „$” (używanego zarówno w shellu, jak i w make), uwzględnienie wcięć.
Wymienione problemy są rozwiązywane w Celach przez użycie symbolu „%” zamiast „$” dla zmiennych budowlanych („$” pozostaje tylko dla shell), przy zastosowaniu parsera , który wymaga otaczania ścieżek i nazw plików cudzysłowami oraz umieszczania bloków kodu w nawiasach klamrowych. Cały blok jest uruchamiany w jednym egzemplarzu powłoki, a wewnątrz bloku dopuszczalne jest dowolne formatowanie kodu, bez powiązania z określonymi spacjami.
Było:
target: foo.o bar.o
${CC} ${CFLAGS} <$ -o $@Stało się:
«target»: «foo.o», «bar.o» {
LAGS < -o %@
}
Inne cechy Goals:
- Opcjonalne wsparcie dla definiowania dowolnych nazw i parametrów:
goal all = : «target»
goal link =
«target» : «foo.o», «bar.o» { … }goal compile (name) =
«%name.o» : «%name.c», «dep.h» { LAGS -c $^ -o $@ } - Dwa tryby uruchamiania: tryb make do mapowania celów budowania na nazwy plików (na przykład plik «foo.o» odpowiada celowi «%name.o»), oraz tryb bezpośredniego uruchomienia kompilacji:
goal all = : link
goal link =
«target» : «foo.o», compile («bar») { … }goal compile (name) =
«%name.o» : «%name.c», «dep.h» { LAGS -c $^ -o $@ } - Taktyka budowy jest definiowana przez specjalne zasady, za pomocą których można określić potrzebę ponownego budowania celu budowania. Jeśli istnieje powiązanie z istnieniem pliku, jest to wyraźnie określane przez odpowiedni wskaźnik («target» dla nazwy zasady i *file(«target») dla sprawdzenia pliku).
«target» : «foo.o», «bar.o» { … }
*file(«target») : *file(«foo.o»), *file(«bar.o») { … }
- Programista może definiować dowolne wskaźniki taktyk budowania. Wskaźnik «*file» jest domyślnie zdefiniowany (@{…} wskazuje na tłumienie wyjścia, a «exit 99» sygnalizuje potrzebę ponownego budowania):
tactic *file (filename) = @{
test -f %filename || exit 99
for f in %Źródło: opennet.ru
