Richard WM Jones, autor , pracujący w Red Hat, nowe narzędzie do montażu , mający na celu wyeliminowanie niedociągnięć i problemów w użyteczności make przy zachowaniu ogólnej prostoty i zrozumiałości skryptów. Narzędzie make zostało zaprojektowane w 1976 roku i ma wiele niedociągnięć koncepcyjnych. Celem firmy jest wyeliminowanie tych niedociągnięć bez zmiany ogólnej koncepcji.
Kod źródłowy celów na licencji GPLv2+.
:
- Obsługa tylko jednej taktyki rozwiązywania zależności - „instrukcja asemblera jest uruchamiana, jeśli brakuje pliku docelowego lub jest starszy niż jedna z zależności”. Goals planuje wdrożyć inne taktyki, takie jak sprawdzanie obecności adresu URL, porównywanie czasów modyfikacji z dowolnym plikiem, ocenianie wbudowanego pakietu , porównywanie sum kontrolnych, uruchamianie przypadków testowych z selektywnym pomijaniem testów.
- Podczas przetwarzania obiektów docelowych kompilacji polecenie make nie oddziela plików i nazw reguł, w wyniku czego nie jest sprawdzane, czy podczas uruchamiania reguły plik, który rzekomo został utworzony, faktycznie zostanie utworzony. Na przykład, jeśli masz regułę o nazwie „test”, która uruchamia skrypty z testami, przypadkowo utworzony zostanie plik o nazwie „test”, wówczas testy nie będą już wywoływane, ponieważ make uzna, że cel jest zbudowany i nie wymaga dowolna akcja (w celu obejścia problemu w programie make możesz określić dyrektywę „.PHONY: test”). Cele wyraźnie oddzielają pliki i nazwy reguł.
- Problem z podaniem tylko jednego parametru dla instrukcji montażu.
Cele umożliwiają użycie dowolnej liczby nazwanych parametrów. Na przykład możesz osobno wyodrębnić znak pliku debugowania z nazwy:
- Problemy z interakcją z interpreterem powłoki. Na przykład konieczność kontrolowania ucieczki spacji w nazwach plików i katalogów, marnowanie zasobów na uruchamianie osobnego interpretera powłoki podczas wykonywania każdego polecenia, podwójna interpretacja znaku „$” (używanego zarówno w powłoce, jak i make), biorąc pod uwagę wcięcia.
Problemy te rozwiązano w Goals, używając symbolu „%” zamiast „$” dla zmiennych asemblerowych („$” pozostaje tylko dla powłoki), używając parsera , co wymaga otoczenia ścieżek i nazw plików cudzysłowami oraz wyróżnienia bloków kodu nawiasami klamrowymi. Cały blok poleceń uruchamiany jest w jednej instancji powłoki poleceń, a w obrębie bloku dozwolone jest dowolne formatowanie kodu, bez odwoływania się do specjalnych spacji.
To było:
cel: foo.o bar.o
${CC} ${CFLAGS} $< -o $@Stało się:
"target": "foo.o", "bar.o" {
%CC %CFLAGS %< -o %@
}
Inne funkcje celów:
- Opcjonalna obsługa określania dowolnych nazw i parametrów:
cel wszystko =: „cel”
link do celu =
"target": "foo.o", "bar.o" {... }kompilacja celu (nazwa) =
"%name.o": "%name.c", "dep.h" {%CC %CFLAGS -c $^ -o $@ } - Dwa tryby uruchamiania: tryb make dopasowujący cele kompilacji do nazw plików (na przykład plik „foo.o” pasuje do celu „%name.o”) oraz tryb kompilacji bezpośredniej:
cel wszystko =: link
link do celu =
„target”: „foo.o”, skompiluj („pasek”) { ... }kompilacja celu (nazwa) =
"%name.o": "%name.c", "dep.h" {%CC %CFLAGS -c $^ -o $@ } - Taktykę montażu określają specjalne zasady, które można wykorzystać do określenia potrzeby ponownego złożenia celu montażu. Jeśli zostanie utworzone powiązanie z obecnością pliku, zostanie to wyraźnie określone poprzez odpowiedni znak („target” w przypadku nazwy reguły i *plik („target”) w celu sprawdzenia pliku).
"target": "foo.o", "bar.o" {... }
*plik("target") : *plik("foo.o"), *plik("bar.o") { ... }
- Programista może zdefiniować dowolne atrybuty taktyki montażu. Domyślnie zdefiniowana jest flaga „*file” (@{...} oznacza wstrzymanie wyjścia, a „exit 99” sygnalizuje potrzebę przebudowy):
taktyka *plik (nazwa pliku) = @{
test -f %nazwa pliku || wyjście 99
dla f w%Źródło: opennet.ru