wady - Online w chmurze

PROGRAM:

IMIĘ

Wady – system konstrukcji oprogramowania

OPIS

Przewodnik i odniesienia do wersji 2.2.0

Prawa autorskie (c) 1996-2000 Free Software Foundation, Inc.

Ten program jest wolnym oprogramowaniem; możesz go redystrybuować i/lub modyfikować na warunkach
Powszechna Licencja Publiczna GNU opublikowana przez Free Software Foundation; albo
wersja 2 Licencji lub (według Twojego wyboru) dowolna nowsza wersja.

Ten program jest rozpowszechniany w nadziei, że będzie przydatny, ale BEZ ŻADNEJ GWARANCJI;
bez dorozumianej gwarancji PRZYDATNOŚCI HANDLOWEJ lub PRZYDATNOŚCI DO OKREŚLONEGO CELU.
Więcej szczegółów znajdziesz w Powszechnej Licencji Publicznej GNU.

Wraz z tym programem powinieneś otrzymać kopię Powszechnej Licencji Publicznej GNU;
zobacz plik KOPIOWANIE. Jeśli nie, napisz do Free Software Foundation, Inc., 59 Temple
Miejsce – Suite 330, Boston, MA 02111-1307, USA.

Wprowadzenie

Wady to system do konstruowania przede wszystkim oprogramowania, ale różni się od niego zupełnie
poprzednich systemów tworzenia oprogramowania. Wady zostały zaprojektowane od podstaw, aby sobie z nimi poradzić
łatwo dzięki budowie oprogramowania rozproszonego w wielu katalogach źródłowych. Cons
ułatwia tworzenie skryptów kompilacji, które są proste, zrozumiałe i łatwe w utrzymaniu.
Wady zapewniają, że złożone oprogramowanie można łatwo i dokładnie odtwarzać.

Firma Cons wykorzystuje wiele technik, aby to wszystko osiągnąć. Scenariusze konstrukcyjne są po prostu
Skrypty Perla, dzięki czemu są łatwe do zrozumienia i bardzo elastyczne. Globalny zakres
zmienne zostały zastąpione mechanizmem importu/eksportu umożliwiającym wymianę informacji pomiędzy
skryptów, znacznie poprawiając czytelność i łatwość konserwacji każdego skryptu.
Budownictwo środowiska zostały wprowadzone: są to obiekty Perla, które przechwytują
informacje wymagane do kontrolowania procesu kompilacji. Używanych jest wiele środowisk
gdy do generowania produktów w drzewie kompilacji wymagana jest inna semantyka. Cons
implementuje automatyczną analizę zależności i wykorzystuje ją do globalnego sekwencjonowania całości
zbudować. Kompilacje wariantów można łatwo utworzyć z jednego drzewa źródłowego. Inteligentna konstrukcja
podzbiór jest możliwy podczas pracy nad zlokalizowanymi zmianami. Można ustawić zastąpienia
łatwo zastąpić instrukcje kompilacji bez modyfikowania jakichkolwiek skryptów. Kryptograficzne MD5
podpisów są powiązane z plikami pochodnymi i służą do dokładnego określenia, czy
dany plik wymaga odbudowania.

Oferując wszystkie powyższe i więcej, Cons pozostaje prosty i łatwy w użyciu. To będzie
miejmy nadzieję, że stanie się to jasne podczas czytania dalszej części tego dokumentu.

Czemu Cons? Czemu nie Robić?

Wady to: robić wymiana. W poniższych akapitach przyjrzymy się kilku z nich
niepożądane cechy marki — i typowe środowiska kompilacji oparte na marce — to
zmotywował rozwój Minusów.

Budować kompleksowość

Tradycyjne systemy oparte na markach dowolnej wielkości stają się dość złożone. Oryginalna marka
użyteczność i jej pochodne przyczyniły się do tej tendencji na wiele sposobów. Zrób jest
nie jest dobry w radzeniu sobie z systemami rozproszonymi w wielu katalogach. Różne prace-
obejścia służą do pokonania tej trudności; typowym wyborem jest wywołanie make
się rekurencyjnie dla każdego podkatalogu kompilacji. Prowadzi to do skomplikowanego kodu, w
dla których często nie jest jasne, w jaki sposób zmienna jest ustawiana lub jaki wpływ ma ustawienie zmiennej
będzie mieć wpływ na całą kompilację. Język skryptowy make był stopniowo rozszerzany
zapewnić więcej możliwości, ale w dużej mierze przyczyniły się one już do zaśmiecenia
przesadnie rozbudowany język. Często kompilacje są wykonywane w wielu przebiegach, aby zapewnić
odpowiednie produkty z jednego katalogu do innego katalogu. Oznacza to dalszy ciąg
wzrost złożoności kompilacji.

Budować odtwarzalność

Zmorą wszystkich marek zawsze była właściwa obsługa zależności. Najczęściej an
podjęto próbę wykonania rozsądnej pracy z zależnościami w jednym katalogu, ale nie
podjęto poważną próbę wykonania zadania między katalogami. Nawet jeśli są zależności
działa poprawnie, w celu ustalenia, czy
plik jest nieaktualny w odniesieniu do osób na jego utrzymaniu, ogólnie rzecz biorąc, nie jest odpowiedni
określenie, kiedy plik powinien zostać ponownie wygenerowany. Jeśli na przykład biblioteka zewnętrzna to
przebudowany, a następnie „wciągnięty” na miejsce, znaczniki czasu na nowo utworzonych plikach mogą
cóż, być wcześniejsza niż ostatnia lokalna kompilacja, ponieważ została zbudowana, zanim stała się widoczna.

Wariant Buduje

Make zapewnia jedynie ograniczone możliwości obsługi kompilacji wariantowych. Wraz z proliferacją
platform sprzętowych i potrzeba debugowalnego i zoptymalizowanego kodu, możliwość
łatwe tworzenie tych wariantów jest niezbędne. Co ważniejsze, jeśli tworzone są warianty, to
ważne jest, aby móc oddzielić warianty lub móc je odtworzyć
oryginał lub wariant do woli. W przypadku make bardzo trudno jest oddzielić kompilacje
wiele katalogów kompilacji, oddzielnych od źródła. A jeśli ta technika nie zostanie zastosowana,
praktycznie nie da się też w żadnym momencie zagwarantować, który wariant będzie dostępny
drzewo, bez uciekania się do całkowitej przebudowy.

Repozytoria

Make zapewnia jedynie ograniczone wsparcie przy tworzeniu oprogramowania z kodu istniejącego w pliku
struktura katalogów centralnego repozytorium. Funkcja VPATH GNU make (i kilka innych
make implements) ma to zapewnić, ale nie działa zgodnie z oczekiwaniami: it
zbyt wcześnie zmienia ścieżkę pliku docelowego na nazwę VPATH i dlatego
wyszukuje wszystkie zależności w katalogu VPATH. Aby zapewnić prawidłowy rozwój
builds, ważna jest możliwość utworzenia pliku w lokalnym katalogu kompilacji i posiadania
dowolne pliki w repozytorium kodu (w skrócie katalog VPATH), które zależą od pliku local
plik zostanie poprawnie odbudowany. Nie jest to możliwe w przypadku VPATH, bez dużej ilości kodowania
złożoną wiedzę o repozytorium bezpośrednio do plików makefile.

Konserwacja it prosty

Kilka problemów związanych z marką zostało przytoczonych powyżej. W tym i kolejnych
W kolejnych rozdziałach przedstawimy wady i pokażemy, jak rozwiązano te problemy.

Perl skrypty

Wady jest oparty na Perlu. Oznacza to, że skrypty wad...Poborowy i Skonstruować pliki, odpowiednik
do Makefile or makefile--są napisane w Perlu. Zapewnia to natychmiastową korzyść:
język do pisania scenariuszy jest znajomy. Nawet jeśli tak się składa, że ​​nie jesteś Perlem
programiście, warto wiedzieć, że Perl jest w zasadzie prostym językiem deklaratywnym,
z dobrze zdefiniowanym przepływem kontroli i znaną semantyką. Zawiera zmienne, które się zachowują
zasadniczo tak, jak można się tego spodziewać, podprogramy, przepływ kontroli i tak dalej. Tam
nie wprowadzono żadnej specjalnej składni dla Cons. Wykorzystanie Perla jako języka skryptowego
upraszcza zadanie wyrażenia odpowiedniego rozwiązania często złożonego
wymagania kompilacji.

Cześć, Świat!

Aby uzasadnić poniższą dyskusję, oto jak można zbudować plik Cześć, Świat! C
aplikacja z wadami:

$env = nowe wady();
Program $env 'hello', 'hello.c';

Jeśli zainstalujesz ten skrypt w katalogu, nadaj mu nazwę Skonstruowaći utwórz plik
cześć, c source w tym samym katalogu, możesz wpisać `cons hello', aby zbudować plik
Aplikacja:

% wad Witam
cc -c hello.c -o hello.o
cc -o cześć, cześć.o

Budownictwo środowiska

Kluczowym uproszczeniem Wady jest koncepcja a Budowa środowisko. Konstrukcja
środowisko jest przedmiot charakteryzujący się zestawem par klucz/wartość i zestawem Metody.
Aby powiedzieć Consowi, jak coś zbudować, wywołujesz odpowiednią metodę poprzez plik
odpowiednie środowisko budowlane. Rozważ następujący przykład:

$env = nowe wady(
CC => 'gcc',
LIBS => 'libworld.a'
);

Program $env 'hello', 'hello.c';

W tym przypadku zamiast korzystać z domyślnego środowiska konstrukcyjnego, jakie mamy
nadpisano wartość `CC', tak że zamiast tego użyto odpowiednika kompilatora GNU C. Od
ta wersja Cześć, Świat! wymaga biblioteki, libworld.a, określiliśmy, że any
program połączony w tym środowisku powinien być połączony z tą biblioteką. Jeśli biblioteka
istnieje już, bardzo dobrze, ale jeśli nie, to będziemy musieli dołączyć również stwierdzenie:

Biblioteka $env 'libworld', 'world.c';

Teraz, jeśli wpiszesz „cons hello”, biblioteka zostanie zbudowana przed połączeniem programu i,
oczywiście do kompilacji obu modułów zostanie użyte `gcc':

% wad Witam
gcc -c hello.c -o hello.o
gcc -c świat.c -o świat.o
ar libworld.a world.o
ar: tworzenie libworld.a
ranlib libworld.a
gcc -o hello hello.o libworld.a

automatycznie i kompletny zależność analiza

W przypadku wad zależności są obsługiwane automatycznie. Kontynuując poprzedni przykład, uwaga
to kiedy modyfikujemy świat.c, świat.o jest rekompilowany, libworld.a odtworzone i cześć
ponownie połączone:

% vi świat.c
[Edycja]
% wad Witam
gcc -c świat.c -o świat.o
ar libworld.a world.o
ar: tworzenie libworld.a
ranlib libworld.a
gcc -o hello hello.o libworld.a

To stosunkowo prosty przykład: Wady „wie” świat.o zależy świat.c, Ponieważ
zależność jest jawnie konfigurowana przez metodę `Library'. To też wie libworld.a
zależy świat.o i że cześć zależy libworld.a, wszystko z podobnych powodów.

Teraz się okazuje cześć, c zawiera także plik definicji interfejsu, świat.h:

% świata emacsa.h
[Edycja]
% wad Witam
gcc -c hello.c -o hello.o
gcc -o hello hello.o libworld.a

Skąd Cons to wie cześć, c obejmuje świat.hI to cześć. o musi więc być
przekompilowany? Na razie wystarczy to powiedzieć przy rozważaniu, czy cześć. o jest na górze-
do tej pory Cons wywołuje skaner ze względu na swoją zależność, cześć, c. Skaner ten wylicza
pliki zawarte przez cześć, c aby sporządzić listę dalszych zależności poza nimi
wyraźnie wyrażone w skrypcie Cons. Ten proces jest rekurencyjny: wszystkie pliki dołączone przez
dołączone pliki również zostaną przeskanowane.

Czy to nie jest drogie? Odpowiedź brzmi – to zależy. Jeśli wykonujesz pełną kompilację dużego systemu,
czas skanowania jest nieznaczny. Jeśli przeprowadzisz przebudowę dużego systemu, pojawią się wady
spędzić sporo czasu myśląc o tym, zanim zdecyduje, że nic nie musi się dziać
gotowe (choć niekoniecznie więcej czasu niż zrobienie!). Dobra wiadomość jest taka, że ​​Cons to robi
bardzo łatwo jest inteligentnie podzielić kompilację na podzbiory, gdy pracujesz nad zlokalizowanymi zmianami.

automatycznie światowy budować sekwencjonowanie

Ponieważ Cons przeprowadza pełną i dokładną analizę zależności i robi to globalnie, dla
całej kompilacji, Cons może wykorzystać te informacje, aby przejąć pełną kontrolę nad sekwencjonowanie
budowy. Kolejność ta jest widoczna w powyższych przykładach i jest z nią równoważna
można się spodziewać po make, biorąc pod uwagę pełny zestaw zależności. W przypadku wad to się rozszerza
trywialnie do większych, wielokatalogowych kompilacji. W rezultacie cała złożoność
w upewnianiu się, że kompilacja jest poprawnie zorganizowana - w tym hierarchiczna wieloprzebiegowa
buduje – jest eliminowany. Omówimy to szerzej w następnych sekcjach.

Budowanie duży drzewa – nadal właśnie as prosty

A hierarchia of budować skrypty

Większa kompilacja w Cons jest zorganizowana poprzez utworzenie hierarchii budować skrypty. Na górze
drzewa to skrypt o nazwie Skonstruować. Reszta skryptów, zgodnie z konwencją, jest każda
nazywa Poborowy. Skrypty te są ze sobą połączone w bardzo prosty sposób poprzez opcję „Buduj”,
Polecenia „Eksportuj” i „Importuj”.

Połączenia Budować komenda

Polecenie „Buduj” pobiera listę Poborowy nazwy plików i organizuje je
zawarte w kompilacji. Na przykład:

Zbuduj qw(
kierowcy/wyświetlacz/poborowy
sterowniki/mysz/poborowy
parser/poborowy
media/poborowy
);

Jest to prosta dwupoziomowa hierarchia skryptów kompilacji: wszystkie zależne Poborowy pliki
są wymienione na najwyższym poziomie Skonstruować plik. Zauważ, że nie wszystkie katalogi w drzewie
koniecznie mają powiązane ze sobą skrypty kompilacji.

Można to również zapisać jako skrypt wielopoziomowy. Na przykład Skonstruować plik może
zawierać to polecenie:

Zbuduj qw(
parser/poborowy
kierowcy/poborowy
media/poborowy
);

oraz Poborowy Plik w sterowniki katalog może zawierać to:

Zbuduj qw(
wystawa/poborowy
mysz/poborowy
);

Doświadczenie pokazało, że pierwszy model jest nieco łatwiejszy do zrozumienia, ponieważ
całe drzewo konstrukcyjne jest rozłożone przed tobą, na najwyższym poziomie. Schematy hybrydowe są
również możliwe. Oddzielnie utrzymywany komponent, który należy włączyć do a
na przykład drzewo kompilacji może zaczepić się o drzewo kompilacji w jednym miejscu, ale zdefiniować własne
hierarchia konstrukcyjna.

Domyślnie Cons nie zmienia swojego katalogu roboczego na katalog zawierający plik a
subsydiarny Poborowy plik, który zawiera. To zachowanie można włączyć w przypadku kompilacji według
określając, na najwyższym poziomie Skonstruować file:

poborowy_chdir 1;

Po włączeniu opcja Wady zmieni się na spółkę zależną Poborowy katalog zawierający plik
podczas czytania tego pliku, a następnie wróć do katalogu najwyższego poziomu, gdy plik
zostało przetworzone.

Oczekuje się, że to zachowanie stanie się ustawieniem domyślnym w niektórych przyszłych wersjach Cons.
Aby przygotować się na to przejście, kompilacje, w których oczekuje się, że wady pozostaną na górze kompilacji
podczas gdy czyta w spółce zależnej Poborowy plik powinien jawnie wyłączyć tę funkcję, ponieważ
następuje:

poborowy_chdir 0;

Względny, najwyższy krewny, i bezwzględny filet Nazwy

Być może zauważyłeś, że nazwy plików określone w poleceniu Build są względne
lokalizacja skryptu, z którego jest wywoływany. Zwykle dotyczy to innych nazw plików
argumenty również do innych poleceń, chociaż równie dobrze moglibyśmy o tym wspomnieć tutaj, jeśli zaczniesz
nazwę pliku ze znakiem skrótu ``#'', wówczas plik ten jest interpretowany względem góry-
katalog poziomu (gdzie plik Skonstruować znajduje się plik). I nic dziwnego, jeśli zaczniesz
z ``/'', wówczas uważa się, że jest to bezwzględna nazwa ścieżki. Dzieje się tak nawet w przypadku systemów
które używają ukośnika odwrotnego zamiast ukośnika do nazywania ścieżek bezwzględnych.

Korzystanie z Moduły in budować skrypty

Możesz wciągnąć moduły do ​​każdego z nich Poborowy plik przy użyciu normalnego „użyj” lub „wymagaj” Perla
sprawozdania:

używaj angielskiego;
wymagaj My::Moduł;

Każde „użycie” lub „wymaganie” wpływa tylko na jedno Poborowy plik, w którym się pojawia. Aby użyć
moduł w wielu Poborowy plików, musisz w każdym z nich umieścić instrukcję „use” lub „require”.
taki, który potrzebuje modułu.

Zakres of zmienne

Najwyższy poziom Skonstruować plik i tyle Poborowy pliki rozpoczynają życie we wspólnym, oddzielnym Perlu
pakiet. Wady steruje tablicą symboli pakietu, dzięki czemu tablica symboli for
każdy skrypt jest pusty, z wyjątkiem Skonstruować plik, który pobiera część wiersza poleceń
argumenty. Dlatego wszystkie ustawiane lub używane zmienne są ustawiane przez skrypt
samego siebie, a nie jakiegoś zewnętrznego skryptu.

Zmienne mogą być jawnie importowany przez skrypt ze skryptu nadrzędnego. Aby zaimportować plik
zmienna, tak musiało być eksportowane przez rodzica i zainicjowany (w przeciwnym razie wystąpi błąd
wystąpi).

Połączenia Export komenda

Polecenie `Eksportuj' zostało użyte jak w poniższym przykładzie:

$env = nowe wady();
$INCLUDE = "#eksportuj/włącz";
$LIB = "#eksport/lib";
Eksportuj qw( env INCLUDE LIB );
Zbuduj qw(util/Conscript);

Wartości prostych zmiennych wymienionych na liście „Eksport” zostaną przesunięte
za pomocą kolejnych poleceń „Buduj”. Polecenie `Eksportuj' wyeksportuje tylko Perl skalarny
zmienne, czyli zmienne, których nazwa zaczyna się od `$'. Inne zmienne, obiekty itp.
można wyeksportować przez odniesienie - ale wszystkie skrypty będą odnosić się do tego samego obiektu i to
obiekt powinien być uważany za przeznaczony tylko do odczytu przez skrypty pomocnicze i przez oryginał
eksportowanie skryptu. Dopuszczalne jest jednak przypisanie nowej wartości do wyeksportowanego skalara
zmienna — która nie zmieni podstawowej zmiennej, do której się odwołujemy. Ta sekwencja np
przykład, jest OK:

$env = nowe wady();
Eksportuj qw( env INCLUDE LIB );
Zbuduj qw(util/Conscript);
$env = nowe wady(CFLAGS => '-O');
Zbuduj qw(inny/poborowy);

Nie ma znaczenia, czy zmienna jest ustawiona przed, czy po poleceniu `Eksportuj'. The
ważną rzeczą jest wartość zmiennej w momencie wykonania polecenia `Buduj'.
To jest to, co zostaje wyrzucone. Nawiasem mówiąc, wszelkie kolejne polecenia „Eksportuj”
unieważnij pierwszą: musisz wymienić wszystkie zmienne, które chcesz wyeksportować w każdej z nich
Polecenie „Eksportuj”.

Połączenia import komenda

Zmienne wyeksportowane poleceniem „Eksportuj” można zaimportować do skryptów pomocniczych za pomocą polecenia
Polecenie „Importuj”. Skrypt pomocniczy zawsze importuje zmienne bezpośrednio z pliku
lepszy scenariusz. Rozważmy ten przykład:

Importuj qw( env INCLUDE );

Jest to dozwolone tylko wtedy, gdy skrypt nadrzędny wyeksportował zarówno `$env', jak i `$INCLUDE'. To też musi
nadały wartości każdej z tych zmiennych. Jedynie skrypt pomocniczy jest w porządku
zaimportuj podzbiór eksportowanych zmiennych (w tym przykładzie `$LIB', który został wyeksportowany przez
w poprzednim przykładzie nie jest importowany).

Wszystkie zaimportowane zmienne są automatycznie reeksportowane, więc sekwencja:

Importuj qw ( env INCLUDE );
Zbuduj qw (poniżej mnie/poborowy);

dostarczy do pliku pomocniczego zarówno `$env', jak i `$INCLUDE'. Jeśli tylko ma być `$env'
wyeksportowany, wówczas wystarczą:

Importuj qw ( env INCLUDE );
Eksportuj qw (środ.);
Zbuduj qw (poniżej mnie/poborowy);

Nie trzeba dodawać, że zmienne mogą być modyfikowane lokalnie przed wywołaniem „Build” na platformie
skrypt pomocniczy.

Budować scenariusz ewaluację zamówienie

Jedynym ograniczeniem dotyczącym kolejności skryptów kompilacji jest to, że są to skrypty nadrzędne
oceniane przed ich gorszymi skryptami. Najwyższy poziom Skonstruować plik to np
oceniane jako pierwsze, a następnie wszelkie gorsze skrypty. To wszystko, co naprawdę musisz wiedzieć
o kolejności oceny, ponieważ kolejność jest generalnie nieistotna. Rozważ następujące
Polecenie „Buduj”:

Zbuduj qw(
kierowcy/wyświetlacz/poborowy
sterowniki/mysz/poborowy
parser/poborowy
media/poborowy
);

Zdecydowaliśmy się na ułożenie nazw skryptów w kolejności alfabetycznej, po prostu dlatego, że jest ich najwięcej
wygodny do celów konserwacyjnych. Zmiana kolejności nie będzie miała żadnego wpływu na
budować.

A Model dla dzielenie pliki

Trochę prosty Konwencje

W każdym złożonym systemie oprogramowania musi istnieć metoda udostępniania produktów kompilacji
przyjęty. Proponujemy prosty zestaw konwencji, których wdrożenie jest banalne
Minusy, ale bardzo skuteczne.

Podstawową zasadą jest wymaganie, aby wszystkie produkty tworzyły produkty, które muszą być współużytkowane
katalogi są udostępniane poprzez katalog pośredni. Zwykle to nazywaliśmy
eksporti, w środowisku C, udostępnił konwencjonalne podkatalogi tego katalogu,
jak na przykład zawierać, lib, kosz, itp.

Katalogi te są definiowane przez najwyższy poziom Skonstruować plik. Prosty Skonstruować plik dla
a Cześć, Świat! aplikacja zorganizowana przy użyciu wielu katalogów może wyglądać następująco:

# Skonstruuj plik dla Hello, World!

# Gdzie umieścić wszystkie nasze wspólne produkty.
$EKSPORT = '#eksport';

Eksportuj qw( WADY OBEJMUJĄ LIB BIN );

# Standardowe katalogi do udostępniania produktów.
$INCLUDE = "$EKSPORT/włącz";
$LIB = "$EKSPORT/lib";
$BIN = "$EKSPORT/pojemnik";

# Standardowe środowisko konstrukcyjne.
$CONS = nowe wady (
CPPPATH => $INCLUDE, # Dołącz ścieżkę dla kompilacji C
LIBPATH => $LIB, # Ścieżka biblioteki do łączenia programów
LIBS => '-lworld', # Lista standardowych bibliotek
);

Zbuduj qw(
cześć/poborowy
świat/poborowy
);

Połączenia świat katalog Poborowy plik wygląda tak:

# Plik poborowy dla świata katalogów
Importuj qw( WADY OBEJMUJĄ LIB );

# Zainstaluj produkty z tego katalogu
Zainstaluj $CONS $LIB, 'libworld.a';
Zainstaluj $CONS $INCLUDE, 'world.h';

# Produkty wewnętrzne
Biblioteka $CONS 'libworld.a', 'world.c';

oraz cześć katalog Poborowy plik wygląda tak:

# Plik poborowy do katalogu hello
Importuj qw(CONS BIN);

# Eksportowane produkty
Zainstaluj $CONS $BIN, 'cześć';

# Produkty wewnętrzne
Zaprogramuj $CONS 'hello', 'hello.c';

Aby skonstruować Cześć, Świat! programu o tej strukturze katalogów, przejdź na najwyższy poziom
katalogu i wywołaj `cons' z odpowiednimi argumentami. W poniższym przykładzie my
powiedz Consowi, aby zbudował katalog eksport. Aby zbudować katalog, Cons rekurencyjnie buduje wszystko
znanych produktów w tym katalogu (oczywiście tylko jeśli wymagają przebudowy). Jeśli którykolwiek z
produkty te zależą od innych produktów w innych katalogach, wówczas zostaną one zbudowane,
też.

% przeciw eksportowi
Zainstaluj world/world.h jako eksport/include/world.h
cc -Iexport/include -c witaj/witaj.c -o witaj/witaj.o
cc -Iexport/include -c świat/świat.c -o świat/świat.o
ar świat/libworld.a świat/świat.o
ar: tworzenie świata/libworld.a
ranlib world/libworld.a
Zainstaluj world/libworld.a jako eksport/lib/libworld.a
cc -o cześć/cześć cześć/cześć.o -Lexport/lib -lworld
Zainstaluj hello/hello jako eksport/bin/hello

Czysty, zrozumiale, niezależny od lokalizacji skrypty

Zauważysz, że dwa Poborowy pliki są bardzo czyste i na temat. Oni po prostu
określ produkty z katalogu i sposób budowania tych produktów. Instrukcje budowania
są minimalne: określają, jakie środowisko konstrukcyjne zastosować, nazwę produktu,
i nazwę wejść. Zauważ również, że skrypty są niezależne od lokalizacji: if you
chcesz zreorganizować swoje drzewo źródłowe, możesz to zrobić: wystarczy zmienić
Skonstruować plik (w tym przykładzie), aby określić nowe lokalizacje pliku Poborowy akta.
użycie drzewa eksportu ułatwia osiągnięcie tego celu.

Zwróć także uwagę, jak Cons dba o drobne szczegóły za Ciebie. Wszystkie eksport katalogi, dla
przykładowo, zostały wykonane automatycznie. Zainstalowane pliki były naprawdę mocno powiązane z plikiem
odpowiednie katalogi eksportu, aby zaoszczędzić miejsce i czas. Ta dbałość o szczegóły oszczędza
wymaga dużo pracy i jeszcze bardziej ułatwia tworzenie prostych, łatwych w utrzymaniu skryptów.

Rozsadzający źródło i budować drzewa

Często pożądane jest, aby wszelkie pliki pochodne z kompilacji były całkowicie oddzielone od pliku
pliki źródłowe. Dzięki temu znacznie łatwiej jest śledzić, co jest plikiem źródłowym i
ułatwia także obsługę wariant kompilacje, szczególnie jeśli chcesz kompilacje wariantowe
współistnieć.

Rozsadzający budować i źródło katalogi za pomocą dotychczasowy Połączyć komenda

Wady zapewniają prosty mechanizm, który obsługuje wszystkie te wymagania. „Łącze”
polecenie jest wywoływane jak w tym przykładzie:

Link 'build' => 'src';

Określone katalogi są „połączone” z określonym katalogiem źródłowym. Załóżmy, że
że skonfigurowałeś katalog źródłowy, src, z podkatalogami świat i cześć pod tym,
jak w poprzednim przykładzie. Następnie można zastąpić oryginalne linie konstrukcyjne
Następujące:

Zbuduj qw(
build/world/Conscript
build/cześć/poborowy
);

Zauważ, że traktujesz Poborowy plik tak, jakby istniał w katalogu kompilacji. Teraz jeśli
wpiszesz to samo polecenie co poprzednio, otrzymasz następujące wyniki:

% przeciw eksportowi
Zainstaluj build/world/world.h jako eksport/include/world.h
cc -Iexport/include -c build/hello/hello.c -o build/hello/hello.o
cc -Iexport/include -c build/world/world.c -o build/world/world.o
ar build/world/libworld.a build/world/world.o
ar: tworzenie build/world/libworld.a
ranlib build/world/libworld.a
Zainstaluj build/world/libworld.a jako eksport/lib/libworld.a
cc -o build/hello/hello build/hello/hello.o -Lexport/lib -lworld
Zainstaluj build/hello/hello jako eksport/bin/hello

Ponownie Cons zadbał o szczegóły za Ciebie. W szczególności zauważysz, że wszystko
kompilacje są wykonywane przy użyciu plików źródłowych i plików obiektowych z katalogu kompilacji. Dla
przykład, build/world/world.o jest skompilowany z build/world/world.c,
eksport/włącz/świat.h jest instalowany z build/world/world.h. Jest to osiągane w większości
systemów poprzez prosty sposób „twardego” łączenia wymaganych plików z każdego źródła
do odpowiedniego katalogu kompilacji.

Linki są poprawnie utrzymywane przez Cons, niezależnie od tego, co zrobisz z katalogiem źródłowym.
Jeśli zmodyfikujesz plik źródłowy, twój edytor może zrobić to „na miejscu” lub może zmienić jego nazwę
najpierw i utwórz nowy plik. W tym drugim przypadku wszelkie twarde łącza zostaną utracone. Minusy będą
wykryje ten warunek, gdy następnym razem plik źródłowy będzie potrzebny i ponownie go połączy
odpowiednio.

Swoją drogą, też to zauważysz Nie konieczne były zmiany w fundamencie Poborowy
akta. I możemy pójść dalej, jak zobaczymy w następnej sekcji.

Wariant Buduje

Cześć, Świat! dla banan i brzoskwinia systemy operacyjne

Kompilacje wariantów wymagają jeszcze jednego prostego rozszerzenia. Weźmy jako przykład A
wymóg umożliwienia kompilacji zarówno dla systemów operacyjnych baNaNa, jak i peAcH. W tym przypadku,
używamy rozproszonego systemu plików, takiego jak NFS, aby uzyskać dostęp do konkretnego systemu, oraz
tylko jeden lub drugi z systemów musi zostać skompilowany dla danego wywołania
„wady”. Oto jeden ze sposobów konfiguracji Skonstruować plik dla naszego Cześć, Świat!
Aplikacja:

# Skonstruuj plik dla Hello, World!

die qq(należy określić system operacyjny), chyba że $OS = $ARG{OS};
die qq(system operacyjny musi być „brzoskwiniowy” lub „bananowy”)
if $OS ne „brzoskwinia” && $OS ne „banan”;

# Gdzie umieścić wszystkie nasze wspólne produkty.
$EXPORT = "#eksport/$OS";

Eksportuj qw( WADY OBEJMUJĄ LIB BIN );

# Standardowe katalogi do udostępniania produktów.
$INCLUDE = "$EKSPORT/włącz";
$LIB = "$EKSPORT/lib";
$BIN = "$EKSPORT/pojemnik";

# Standardowe środowisko konstrukcyjne.
$CONS = nowe wady (
CPPPATH => $INCLUDE, # Dołącz ścieżkę dla kompilacji C
LIBPATH => $LIB, # Ścieżka biblioteki do łączenia programów
LIBS => '-lworld', # Lista standardowych bibliotek
);

# $BUILD to miejsce, w którym wszystko wyprowadzimy.
$BUILD = "#kompilacja/$OS";

# Powiedz przeciwnikom, gdzie znajdują się pliki źródłowe $BUILD.
Link $BUILD => 'źródło';

Zbudować (
"$BUILD/cześć/poborowy",
"$BUILD/świat/poborowy",
);

Teraz, jeśli zalogujemy się do systemu peAcH, możemy zbudować nasz Cześć, Świat! wniosek o to
Platforma:

% wad eksportu OS=brzoskwinia
Zainstaluj build/peach/world/world.h jako eksport/peach/include/world.h
cc -Iexport/peach/include -c build/peach/hello/hello.c -o build/peach/hello/hello.o
cc -Iexport/peach/include -c build/peach/world/world.c -o build/peach/world/world.o
ar build/peach/world/libworld.a build/peach/world/world.o
ar: tworzenie build/peach/world/libworld.a
ranlib build/peach/world/libworld.a
Zainstaluj build/peach/world/libworld.a jako eksport/peach/lib/libworld.a
cc -o build/peach/hello/hello build/peach/hello/hello.o -Lexport/peach/lib -lworld
Zainstaluj build/peach/hello/hello jako eksport/peach/bin/hello

Wariacje on a motyw

Możliwe są inne warianty tego modelu. Na przykład możesz zdecydować, że chcesz
aby oddzielić pliki dołączane na pliki zależne od platformy i niezależne od platformy.
W tym przypadku musiałbyś zdefiniować alternatywę dla `$INCLUDE' dla zależności od platformy
akta. Bardzo Poborowy plików, generujących całkowicie niezależne od platformy pliki dołączane
nie trzeba zmieniać.

Możesz także chcieć skompilować cały system z debugowaniem lub profilowaniem,
na przykład włączone. Można to zrobić za pomocą odpowiednich opcji wiersza poleceń, takich jak
`DEBUG=wł.'. Zostałoby to następnie przetłumaczone na odpowiednią platformę
wymagania umożliwiające debugowanie (może to obejmować wyłączenie optymalizacji, np
przykład). Opcjonalnie możesz zmieniać przestrzeń nazw dla tych różnych typów systemów,
ale, jak zobaczymy w następnej sekcji, tak nie jest niezbędny aby to zrobić, ponieważ Wady są ładne
mądrze, jeśli chodzi o odbudowę rzeczy po zmianie opcji.

Podpisy

MD5 kryptograficzny podpisów

Ilekroć Cons tworzy plik pochodny, przechowuje plik podpis dla tego pliku. Podpis
jest przechowywany w oddzielnym pliku, po jednym na katalog. Po skompilowaniu poprzedniego przykładu
dotychczasowy .frachtować Plik w kompilacja/brzoskwinia/świat katalog wyglądał tak:

world.o:834179303 23844c0b102ecdc0b4548d1cd1cbd8c6
libworld.a:834179304 9bf6587fa06ec49d864811a105222c00

Pierwsza liczba to znacznik czasu — w przypadku systemów UNIX jest to zazwyczaj liczba
sekund od 1 stycznia 1970. Druga wartość to suma kontrolna MD5. The Wiadomość Digest
Algorytm to algorytm, który na podstawie ciągu wejściowego oblicza silną wartość kryptograficzną
podpis dla tego ciągu. Suma kontrolna MD5 przechowywana w pliku .frachtować plik jest w rzeczywistości plikiem a
skrót wszystkich informacji o zależnościach dla określonego pliku. I tak na przykład dla
świat.o plik, obejmuje to co najmniej plik świat.c plik, a także wszelkie pliki nagłówkowe, które Cons
wie o tym, są uwzględnione, bezpośrednio lub pośrednio, przez świat.c. Nie tylko to, ale
rzeczywista linia poleceń, która została użyta do wygenerowania świat.o jest również uwzględniane w obliczeniach
podpis. Podobnie, libworld.a otrzymuje podpis, który „zawiera” wszystkie
podpisy jego składników (a więc przechodnio podpisy ich
składniki), a także wiersz poleceń, który utworzył plik.

Podpis pliku niepochodnego jest domyślnie obliczany na podstawie bieżącego
czas modyfikacji pliku i nazwę wpisu pliku (chyba że istnieje plik
aktualne .frachtować wpis dla tego pliku, w którym to przypadku używany jest ten podpis).

Należy zauważyć, że plik pochodny nie musi zależeć od żadnego szczegółu Skonstruować or
Poborowy plik — jeśli zmiany w tych plikach mają wpływ na dany plik, to tak będzie
automatycznie odzwierciedlone w jego podpisie, ponieważ odpowiednie części wiersza poleceń są
zawarte w podpisie. Niepowiązane zmiany nie będą miały żadnego skutku.

Kiedy Cons rozważa, czy wyprowadzić konkretny plik, najpierw oblicza
oczekiwany podpis pliku. Następnie porównuje czas ostatniej modyfikacji pliku z
czas zapisany w .frachtować wpis, jeśli taki istnieje. Jeśli te czasy się zgadzają, to
podpis przechowywany w .frachtować plik uznaje się za prawidłowy. Jeśli plik jest poprzedni
podpis nie pasuje do nowego, oczekiwanego podpisu, wówczas plik należy wygenerować ponownie.

Zauważ, że plik zostanie ponownie wygenerowany za każdym razem, gdy zmieni się cokolwiek w pliku zależnym. W
szczególnie, zauważ to każdy zmiana czasu modyfikacji osoby zależnej (do przodu lub
wstecz w czasie) wymusi rekompilację pliku pochodnego.

Wykorzystanie tych podpisów jest niezwykle prostą, wydajną i skuteczną metodą
poprawiając – radykalnie – odtwarzalność systemu.

Zademonstrujemy to na prostym przykładzie:

# Proste „Witaj, świecie!” Konstruuj plik
$CFLAGS = '-g' jeśli $ARG{DEBUG} eq 'włączony';
$CONS = nowe wady(CFLAGS => $CFLAGS);
Zaprogramuj $CONS 'hello', 'hello.c';

Zwróć uwagę, jak Cons rekompilują się w odpowiednich momentach:

% wad Witam
cc -c hello.c -o hello.o
cc -o cześć, cześć.o
% wad Witam
wady: „cześć” jest aktualne.
% wad DEBUG=na cześć
cc -g -c hello.c -o hello.o
cc -o cześć, cześć.o
% wad DEBUG=na cześć
wady: „cześć” jest aktualne.
% wad Witam
cc -c hello.c -o hello.o
cc -o cześć, cześć.o

Code Repozytoria

Wiele organizacji zajmujących się tworzeniem oprogramowania ma jeden lub więcej centralnych katalogów repozytoriów
drzewa zawierające aktualny kod źródłowy dla jednego lub większej liczby projektów, a także pochodne
pliki obiektowe, biblioteki i pliki wykonywalne. Aby ograniczyć niepotrzebną ponowną kompilację,
przydatne jest użycie plików z repozytorium do budowy oprogramowania deweloperskiego – zakładając, że
oczywiście, że w lokalnym drzewie kompilacji nie istnieje żaden nowszy plik zależności.

Magazyn

Cons udostępnia mechanizm pozwalający określić listę repozytoriów kodu, które będą przeszukiwane,
w kolejności dla plików źródłowych i plików pochodnych, których nie znaleziono w lokalnym drzewie katalogów kompilacji.

Następujące linie w a Skonstruować plik poinstruuje Minusów, aby najpierw zajrzeli do pliku
/usr/eksperyment/repozytorium katalogu, a następnie w katalogu /usr/produkt/repozytorium katalog:

Repozytorium qw (
/usr/eksperyment/repozytorium
/usr/produkt/repozytorium
);

Określone katalogi repozytoriów mogą zawierać pliki źródłowe, pliki pochodne (obiekty,
biblioteki i pliki wykonywalne) lub jedno i drugie. Jeśli nie ma pliku lokalnego (źródłowego lub pochodnego) w pliku
katalog, w którym wykonywany jest Cons, a następnie pierwsza znaleziona kopia pliku o tej samej nazwie
w katalogu repozytorium zostaną użyte do zbudowania lokalnych plików pochodnych.

Cons utrzymuje jedną globalną listę katalogów repozytoriów. Wady wyeliminują
bieżący katalog i wszystkie nieistniejące katalogi z listy.

Odkrycie dotychczasowy Skonstruować filet in a Magazyn

Wady również będą szukać Skonstruować i Poborowy plików w drzewie lub drzewach repozytorium.
Prowadzi to jednak do sytuacji jak kura z jajkiem: jak wyglądasz w drzewie repozytorium
dla Skonstruować plik, jeśli Skonstruować plik informuje, gdzie jest repozytorium? Aby dostać
w związku z tym repozytoria można określić za pomocą opcji `-R' w wierszu poleceń:

% cons -R /usr/experiment/repository -R /usr/product/repository .

Wszelkie katalogi repozytoriów określone w pliku Skonstruować or Poborowy pliki zostaną dołączone
do katalogów repozytoriów określonych opcjami `-R' wiersza poleceń.

Magazyn źródło pliki

Jeśli kod źródłowy (w tym plik Poborowy plik) dla wersji bibliotecznej pliku Cześć,
Świat! Aplikacja C znajduje się w repozytorium (bez plików pochodnych), Wady użyją pliku
pliki źródłowe repozytorium w celu utworzenia lokalnych plików obiektowych i pliku wykonywalnego:

% cons -R /usr/src_only/repository hello
gcc -c /usr/src_only/repository/hello.c -o hello.o
gcc -c /usr/src_only/repository/world.c -o świat.o
ar libworld.a world.o
ar: tworzenie libworld.a
ranlib libworld.a
gcc -o hello hello.o libworld.a

Utworzenie lokalnego pliku źródłowego spowoduje, że Cons odbuduje odpowiedni plik pochodny lub
plików:

% pico world.c
[Edycja]
% cons -R /usr/src_only/repository hello
gcc -c świat.c -o świat.o
ar libworld.a world.o
ar: tworzenie libworld.a
ranlib libworld.a
gcc -o hello hello.o libworld.a

Usunięcie lokalnego pliku źródłowego spowoduje, że Cons powróci do budowania pliku pochodnego
pliki ze źródła repozytorium:

% rm świat.c
% cons -R /usr/src_only/repository hello
gcc -c /usr/src_only/repository/world.c -o świat.o
ar libworld.a world.o
ar: tworzenie libworld.a
ranlib libworld.a
gcc -o hello hello.o libworld.a

Magazyn pochodny pliki

Jeśli drzewo repozytorium zawiera pliki pochodne (zwykle pliki obiektowe, biblioteki lub
pliki wykonywalne), Cons wykona normalne obliczenia podpisu, aby zdecydować, czy plik
plik repozytorium jest aktualny lub plik pochodny musi zostać zbudowany lokalnie. To znaczy że,
aby zapewnić prawidłowe obliczenie podpisu, drzewo repozytorium musi również zawierać plik
.frachtować pliki, które zostały utworzone przez Consa podczas generowania plików pochodnych.

Zwykle można to osiągnąć poprzez zbudowanie oprogramowania w repozytorium (lub,
alternatywnie w katalogu kompilacji, a następnie kopiując wynik do repozytorium):

% cd /usr/all/repozytorium
% wad Witam
gcc -c hello.c -o hello.o
gcc -c świat.c -o świat.o
ar libworld.a world.o
ar: tworzenie libworld.a
ranlib libworld.a
gcc -o hello hello.o libworld.a

(Jest to bezpieczne, nawet jeśli Skonstruować lista plików /usr/all/repozytorium katalog w a
Komenda `Repository', ponieważ Wady usuną bieżący katalog z repozytorium
lista.)

Teraz, jeśli chcemy zbudować kopię aplikacji z naszą własną cześć, c plik, potrzebujemy tylko
aby utworzyć jeden niezbędny plik źródłowy i użyć opcji `-R', aby przeciwnicy użyli innego
pliki z repozytorium:

%mkdir $HOME/build1
%cd $HOME/kompilacja1
% wyd hello.c
[Edycja]
% cons -R /usr/all/repository hello
gcc -c hello.c -o hello.o
gcc -o hello hello.o /usr/all/repository/libworld.a

Zauważ, że Cons nie zadał sobie trudu odtworzenia lokalnego libworld.a bibliotekę (lub przekompiluj plik
świat.o moduł), ale zamiast tego używa już skompilowanej wersji z repozytorium.

Ponieważ podpisy MD5, które Cons umieszcza w pliku .frachtować plik zawiera znaczniki czasu dla
pochodnych, znaczniki czasu podpisu muszą być zgodne ze znacznikami czasu pliku, w którym ma zostać złożony podpis
uznać za ważne.

Niektóre systemy oprogramowania mogą zmieniać znaczniki czasu plików repozytorium (kopiując je,
np.), w którym to przypadku Minusy domyślnie założą, że podpisy repozytorium są nieprawidłowe
i niepotrzebnie odbudowuj pliki. To zachowanie można zmienić, określając:

Repozytorium_Sig_Times_OK 0;

To mówi Consowi, aby ignorował znaczniki czasu przy podejmowaniu decyzji, czy podpis jest ważny. (Notatka
że unikanie tej kontroli poprawności oznacza, że ​​repozytorium musi mieć odpowiednią kontrolę
drzewo, aby mieć pewność, że pliki pochodne nie będą mogły być modyfikowane bez aktualizacji pliku .frachtować
podpis.)

miejscowy kopie of pliki

Jeśli drzewo repozytorium zawiera pełne wyniki kompilacji, z której staramy się budować
repozytorium bez żadnych plików w naszym lokalnym drzewie, co jest umiarkowanie zaskakujące
dzieje się:

%mkdir $HOME/build2
%cd $HOME/kompilacja2
% cons -R /usr/all/repository hello
wady: „cześć” jest aktualne.

Dlaczego Cons twierdzi, że cześć program jest aktualny, gdy go nie ma cześć program w
lokalny katalog kompilacji? Ponieważ repozytorium (nie katalog lokalny) zawiera plik
nowomodny cześć program, a Cons prawidłowo określa, że ​​nie trzeba nic robić
odbuduj tę aktualną kopię pliku.

Jednakże w wielu przypadkach właściwym jest zapewnienie lokalnej kopii pliku
plik zawsze istnieje. Na przykład skrypt pakujący lub testujący może zakładać, że jest to pewne
wygenerowane pliki istnieją lokalnie. Zamiast uświadamiać te skrypty pomocnicze o
repozytorium, polecenie `Local' może zostać dodane do pliku Skonstruować or Poborowy złożyć do
określ, że określony plik lub pliki muszą pojawić się w lokalnym katalogu kompilacji:

Lokalne qw(
cześć
);

Następnie, jeśli ponownie uruchomimy to samo polecenie, Cons utworzy lokalną kopię programu z pliku
kopia repozytorium (z informacją, że to robi):

% cons -R /usr/all/repository hello
Lokalna kopia hello z /usr/all/repository/hello
wady: „cześć” jest aktualne.

Zauważ, że ponieważ czynność tworzenia kopii lokalnej nie jest uważana za „kompilację” pliku
cześć plik, Cons nadal raportuje, że jest on aktualny.

Tworzenie kopii lokalnych jest najbardziej przydatne w przypadku plików instalowanych w pliku
katalog pośredni (w celu współdzielenia z innymi katalogami) za pomocą polecenia „Zainstaluj”.
Do polecenia „Zainstaluj” dla pliku dołączone jest polecenie „Lokalne”.
często zdarza się, że Cons udostępnia polecenie `Install_Local' jako wygodny sposób wykonania obu czynności:

Zainstaluj_Local $env, '#export', 'witaj';

jest dokładnie odpowiednikiem:

Zainstaluj $env '#export', 'cześć';
Lokalny „#export/witaj”;

Zarówno polecenia `Local', jak i `Install_Local' aktualizują plik local .frachtować plik z
odpowiednie podpisy plików, dzięki czemu przyszłe kompilacje będą wykonywane poprawnie.

Magazyn zależność analiza

Ze względu na wbudowane skanowanie Cons przeszuka określone drzewa repozytoriów pod kątem uwzględnienia
.h akta. Tak będzie, chyba że kompilator będzie wiedział również o drzewach repozytoriów
niemożliwe do znalezienia .h pliki, które istnieją tylko w repozytorium. Jeżeli np cześć, c
plik zawiera Cześć h plik w jego bieżącym katalogu:

% cons -R /usr/all/repository hello
gcc -c /usr/all/repository/hello.c -o hello.o
/usr/all/repository/hello.c:1: hello.h: Nie ma takiego pliku ani katalogu

Rozwiązanie tego problemu narzuca pewne wymagania na środowisko budowlane
zdefiniowane i na sposób, w jaki dyrektywa preprocesora C `#include' jest używana do dołączania plików.

Aby poinformować kompilator o drzewach repozytoriów, Cons doda odpowiednie `-I'
flagi do poleceń kompilacji. Oznacza to, że zmienna `CPPPATH' w pliku
środowisko konstrukcyjne musi jawnie określać wszystkie podkatalogi, które mają być przeszukiwane
dla dołączonych plików, łącznie z bieżącym katalogiem. W związku z tym możemy naprawić powyższe
na przykład zmieniając tworzenie środowiska w pliku Skonstruować plik w następujący sposób:

$env = nowe wady(
CC => 'gcc',
CPPPATH => '.',
LIBS => 'libworld.a',
);

Ze względu na definicję zmiennej `CPPPATH' daje to efekt, gdy ponownie wykonamy
polecenie:

% cons -R /usr/all/repository hello
gcc -c -I. -I/usr/all/repository /usr/all/repository/hello.c -o hello.o
gcc -o hello hello.o /usr/all/repository/libworld.a

Kolejność flag `-I' replikuje dla preprocesora C to samo repozytorium-
ścieżka wyszukiwania katalogu, której Cons używa do własnej analizy zależności. Jeśli tam są
wiele repozytoriów i wiele katalogów `CPPPATH', Wady dołączą repozytorium
katalogi na początek każdego katalogu `CPPPATH', szybko mnożąc liczbę
flag `-ja'. Jako skrajny przykład A Skonstruować plik zawierający:

Repozytorium qw(
/u1
/u2
);

$env = nowe wady(
CPPPATH => 'a:b:c',
);

Dałoby polecenie kompilacji:

cc -Ia -I/u1/a -I/u2/a -Ib -I/u1/b -I/u2/b -Ic -I/u1/c -I/u2/c -c hello.c -o cześć.o

Ponieważ Cons opiera się na flagach `-I' kompilatora, aby przekazać kolejność, w jakiej
Należy przeszukać katalogi repozytoriów, natomiast w przypadku katalogów repozytoriów wadą jest
zasadniczo niezgodne z używaniem podwójnych cudzysłowów w dyrektywach `#include' w twoim C
kod źródłowy:

#include "file.h" /* NIE UŻYWAJ TAKICH PODWÓJNYCH CYTATY */

Dzieje się tak dlatego, że większość preprocesorów C, w obliczu takiej dyrektywy, zawsze będzie pierwsza
przeszukaj katalog zawierający plik źródłowy. Podważa to skomplikowane „-ja”
opcje, które Cons konstruuje, aby preprocesor był zgodny z preferowanym wyszukiwaniem
ścieżka.

W związku z tym, korzystając z drzew repozytoriów w wadach, zawsze użyj nawiasów kątowych dla dołączonych
plików:

#włączać /* ZAMIAST UŻYJ NAWIASÓW KĄTOWYCH */

Lista_repozycji

Wada udostępnia polecenie `Repository_List', które zwraca listę wszystkich katalogów repozytoriów
w bieżącej kolejności wyszukiwania. Można tego użyć do debugowania lub do wykonania bardziej złożonego Perla
rzeczy:

@list = Lista_repozycji;
print Join(' ', @list), "\n";

Magazyn wzajemne oddziaływanie w inny Wady cechy

Obsługa drzew repozytoriów przez Wady poprawnie współdziała z innymi funkcjami Wady, czyli
powiedzieć, że generalnie robi to, czego można się spodziewać.

Co najważniejsze, drzewa repozytoriów współdziałają poprawnie i dość skutecznie z „Łączem”
Komenda. Drzewo repozytorium może zawierać jeden lub więcej podkatalogów do kompilacji wersji
ustanowiony poprzez `Link' do podkatalogu źródłowego. Wady będą szukać plików pochodnych w
odpowiednie podkatalogi kompilacji w drzewie repozytorium.

Domyślnie cele

Do tej pory pokazaliśmy wywoływanie Cons z wyraźnym celem do zbudowania:

% wad Witam

Zwykle Cons nie buduje niczego, chyba że określono cel, ale określono „.”
(bieżący katalog) zbuduje wszystko:

% cons # nic nie buduje

% Cons . # buduje wszystko w katalogu najwyższego poziomu

Dodanie metody `Default' do any Skonstruować or Poborowy plik doda określone
targets do listy domyślnych celów. Wady zbudują te ustawienia domyślne, jeśli ich nie ma
cele określone w wierszu poleceń. Dodajmy więc następujący wiersz do najwyższego poziomu
Skonstruować plik będzie domyślnie naśladował typowe zachowanie Make polegające na budowaniu wszystkiego:

Domyślny '.';

Poniższe dodałoby cześć i do widzenia polecenia (w tym samym katalogu co plik
Skonstruować or Poborowy plik) do listy domyślnej:

Domyślne qw(
cześć
do widzenia
);

Metody „Domyślnej” można użyć więcej niż raz, aby dodać cele do listy domyślnej.

Selektywny Buduje

Wady zapewniają dwie metody zmniejszania rozmiaru danej kompilacji. Pierwsza polega na określeniu
targets w wierszu poleceń, a druga to metoda czyszczenia drzewa kompilacji. Dobrze
najpierw rozważ specyfikację celu.

Selektywny kierowania

Podobnie jak make, Cons pozwala na określenie ``celów'' w linii poleceń. Cele wady
mogą to być pliki lub katalogi. Gdy określony jest katalog, jest to po prostu skrót
Ręczna notacja dla każdego możliwego do wyprowadzenia produktu – o którym Cons wie – w określonym
katalog i poniżej. Na przykład:

% wad build/hello/hello.o

znaczy budować cześć. o i wszystko to cześć. o może potrzebować. To jest z poprzedniego
wersja Cześć, Świat! program w którym cześć. o zależało od
eksport/włącz/świat.h. Jeśli ten plik nie jest aktualny (ponieważ ktoś zmodyfikował
src/świat/świat.h), wówczas zostanie odbudowany, nawet jeśli znajduje się w katalogu zdalnym
budować/cześć.

W tym przykładzie:

% wad kompilacji

Wszystko w budować Jeśli to konieczne, tworzony jest katalog. Ponownie może to spowodować pojawienie się większej liczby plików
powstać. W szczególności oba eksport/włącz/świat.h i eksport/lib/libworld.a jest
wymagane przez budować/cześć katalog i dlatego zostaną zbudowane, jeśli będą nieaktualne.

Jeśli to zrobimy, zamiast tego:

% przeciw eksportowi

wówczas odbudowane zostaną tylko pliki, które powinny zostać zainstalowane w katalogu eksportu, jeśli
konieczne, a następnie tam zainstalowane. Zauważ, że `cons build' może tworzyć pliki, które `cons build' mogą tworzyć pliki, które `cons build' mogą tworzyć pliki `cons build'
eksport” nie buduje się i odwrotnie.

Nie „specjalny” cele

W przypadku wad, cele „specjalne” w stylu make nie są wymagane. Najprostszy analog z wadami
jest użycie specjalnego eksport zamiast tego katalogi. Załóżmy na przykład, że masz
całą serię testów jednostkowych powiązanych z Twoim kodem. Testy żyją w
katalog źródłowy w pobliżu kodu. Zwykle jednak nie chcesz tworzyć tych testów.
Jednym z rozwiązań jest dostarczenie wszystkich instrukcji kompilacji dotyczących tworzenia testów, a następnie
zainstaluj testy w osobnej części drzewa. Jeśli zainstalujemy testy na najwyższym poziomie
katalog o nazwie Testy, następnie:

Testy % wad

zbuduje wszystkie testy.

% przeciw eksportowi

zbuduje wersję produkcyjną systemu (ale nie wersję testową) oraz:

% wad kompilacji

prawdopodobnie należy tego unikać (ponieważ spowoduje to niepotrzebne kompilowanie testów).

Jeśli chcesz zbudować tylko jeden test, możesz jawnie nazwać test (w
albo Testy katalog lub budować informator). Można także agregować testy
w wygodną hierarchię w katalogu testów. Ta hierarchia nie musi
koniecznie pasują do hierarchii źródłowej, w podobny sposób, jak hierarchia dołączeń
prawdopodobnie nie pasuje do hierarchii źródłowej (jest mało prawdopodobne, aby hierarchia dołączania była większa
głębokość niż dwa poziomy w przypadku programów w języku C).

Jeśli chcesz zbudować absolutnie wszystko w drzewie (w zależności od opcji, które masz
wybierz), możesz użyć:

% Cons .

Nie jest to szczególnie wydajne, ponieważ będzie redundantnie chodzić po wszystkich drzewach,
łącznie z drzewem źródłowym. Drzewo źródłowe może oczywiście zawierać obiekty do zbudowania
to — nic nie stoi na przeszkodzie, aby to zrobić, nawet jeśli zwykle tworzysz osobną kompilację
drzewo.

Budować Przycinanie

W połączeniu z wyborem celu, budować przycinanie można wykorzystać do ograniczenia zakresu
zbudować. W poprzednim przykładzie peAcH i baNaNa widzieliśmy już, jak działa to za pomocą skryptu
można zastosować przycinanie kompilacji, aby udostępnić tylko połowę potencjalnej kompilacji dla dowolnego elementu
przywoływanie „wad”. Wady zapewniają także dla wygody konwencję wiersza poleceń, zgodnie z którą
pozwala określić które Poborowy pliki faktycznie są „budowane” – to znaczy włączane
do drzewa kompilacji. Na przykład:

% wad kompilacji +świat

Argument `+' wprowadza wyrażenie regularne Perla. Należy to oczywiście zacytować
poziom powłoki, jeśli w wyrażeniu znajdują się metaznaki powłoki. The
wyrażenie jest dopasowywane do każdego z nich Poborowy plik, który został wspomniany w `Build'
instrukcję i tylko te skrypty o pasujących nazwach są faktycznie włączane do pliku
zbudować drzewo. Dopuszczalnych jest wiele takich argumentów, w takim przypadku dopasowanie do dowolnego z nich
wystarczy, aby spowodować dołączenie skryptu.

W powyższym przykładzie cześć program nie zostanie zbudowany, ponieważ wady nie będą miały żadnych
znajomość scenariusza cześć/poborowy, libworld.a archiwum zostanie zbudowane, jeśli jednak
trzeba.

Istnieje kilka zastosowań czyszczenia kompilacji za pomocą wiersza poleceń. Być może najbardziej przydatny
jest umiejętność dokonywania zmian lokalnych, a następnie przy odpowiedniej wiedzy nt
konsekwencje tych zmian, ogranicz rozmiar drzewa kompilacji, aby przyspieszyć
czas odbudowy. Drugim zastosowaniem czyszczenia kompilacji jest aktywne zapobieganie ponownej kompilacji
niektórych plików, o których wiesz, że zostaną ponownie skompilowane z powodu, na przykład, zmodyfikowanego pliku nagłówkowego.
Być może wiesz, że albo zmiany w pliku nagłówkowym są nieistotne, albo że plik
zmiany można bezpiecznie zignorować w większości drzewa do celów testowych. Wady:
pogląd jest taki, że pragmatyczne jest akceptowanie tego typu zachowań ze świadomością, że
przy następnej pełnej kompilacji wszystko, co wymaga przebudowy, będzie. Nie ma odpowiednika
na polecenie ``make touch'', aby oznaczyć pliki jako trwale aktualne. Zatem jakiekolwiek ryzyko
poniesione w wyniku czyszczenia kompilacji jest łagodzony. Oczywiście zalecamy, jeśli chodzi o pracę związaną z jakością wydania
że nie używasz czyszczenia kompilacji (można go jednak używać podczas integracji, jednak
do sprawdzania kompilacji itp. Pamiętaj tylko, aby przed zatwierdzeniem wykonać nieograniczoną kompilację
integracja).

praca tymczasowa nadpisuje

Wady zapewniają bardzo prosty mechanizm zastępowania aspektów kompilacji. Istotą jest
że napiszesz plik przesłonięcia zawierający jedno lub więcej poleceń przesłonięcia i ty
określ to w wierszu poleceń, kiedy uruchomisz `cons':

% wad -o nad eksportem

zbuduje eksport katalog, w którym znajdują się wszystkie pliki pochodne podlegające zastąpieniu
koniec plik. Jeśli pominiesz opcję `-o', wówczas wszystko, co niezbędne, zostanie usunięte
wszystkie nadpisania zostaną odbudowane.

Nadrzędny środowisko zmienne

Plik przesłonięć może zawierać dwa typy przesłonięć. Pierwszym z nich jest środowisko przychodzące
zmienne. Są one zwykle dostępne przez Skonstruować plik z hashem `%ENV'
zmienny. Można je w prosty sposób zastąpić w pliku zastąpień, ustawiając opcję
odpowiednie elementy `%ENV' (można je również nadpisać w środowisku użytkownika,
oczywiście).

Połączenia Zastąp komenda

Drugi rodzaj zastąpienia jest realizowany za pomocą polecenia „Zastąp”, które wygląda następująco
to:

Nadpisanie , => , => , ...;

Wyrażenie regularne regexp jest porównywany z każdym plikiem pochodnym będącym kandydatem
dla budowy. Jeśli plik pochodny pasuje, używane są pary zmienna/wartość
nadpisać wartości w środowisku konstrukcyjnym skojarzone z plikiem pochodnym.

Załóżmy, że mamy takie środowisko konstrukcyjne:

$CONS = nowe wady(
COPT => '',
CDBG => '-g',
CFLAGS => '%COPT %CDBG',
);

Następnie, jeśli mamy plik zastępujący koniec zawierający to polecenie:

Zastąp '\.o$', COPT => '-O', CDBG => '';

następnie wywołanie „wad” z „-o over”, które spowoduje utworzenie .o pliki za pośrednictwem tego środowiska
powodują ich kompilację z `-O' i bez `-g'. Oczywiście przesunięcie mogłoby nastąpić
ograniczone do jednego katalogu poprzez odpowiedni wybór wyrażenia regularnego.

Oto oryginalna wersja Hello, World! program zbudowany w tym środowisku.
Zauważ, że Cons odbudowuje odpowiednie elementy po zastosowaniu lub usunięciu zastąpienia:

% wad Witam
cc -g -c hello.c -o hello.o
cc -o cześć, cześć.o
% wad -o na cześć
cc -O -c hello.c -o hello.o
cc -o cześć, cześć.o
% wad -o na cześć
wady: „cześć” jest aktualne.
% wad Witam
cc -g -c hello.c -o hello.o
cc -o cześć, cześć.o

Ważne jest, aby polecenie „Zastąp” było używane tylko tymczasowo, w locie
zastąpienia niezbędne do programowania, ponieważ zastąpienia nie są niezależne od platformy i
ponieważ w zbyt dużym stopniu polegają na dogłębnej znajomości działania skryptów. Dla
tymczasowego użytku, jednak są dokładnie tym, czego chcesz.

Pamiętaj, że nadal przydatne jest zapewnienie, powiedzmy, możliwości stworzenia w pełni zoptymalizowanego
wersja systemu do użytku produkcyjnego - z Skonstruować i Poborowy akta. Tą drogą
możesz dostosować zoptymalizowany system do platformy. Tam, gdzie konieczne są kompromisy w zakresie optymalizacji
made (np. określone pliki mogą nie zostać skompilowane przy pełnej optymalizacji).
można je zapisać dla potomności (i odtwarzalności) bezpośrednio w skryptach.

Więcej on Budowa środowiska

Domyślnie Budowa zmienne

Wspomnieliśmy i wykorzystaliśmy koncepcję a Budowa środowisko, wiele razy w
poprzednie strony. Nadszedł czas, aby uczynić to trochę bardziej konkretnym. Z następującymi
komunikat:

$env = nowe wady();

tworzone jest odniesienie do nowego, domyślnego środowiska konstrukcyjnego. Zawiera liczbę
zmiennych konstrukcyjnych i niektórych metod. W chwili obecnej domyślna lista
zmienne konstrukcyjne definiuje się w następujący sposób:

CC => „cc”,
CFLAGI => '',
CCCOM => '%CC %CFLAGS %_IFLAGS -c %< -o %>',
INCDIRPREFIX => '-I',
CXX => '%CC',
CXXFLAGS => '%CFLAGS',
CXXCOM => '%CXX %CXXFLAGS %_IFLAGS -c %< -o %>',
LINK => '%CXX',
LINKCOM => '%LINK %LDFLAGS -o %> %< %_LDIRS %LIBS',
LINKMODULECOM => '%LD -r -o %> %<',
LIBDIRPREFIX => '-L',
AR => 'ar',
ARFLAGI => 'r',
ARCOM => "%AR %ARFLAGS %> %<\n%RANLIB %>",
RANLIB => 'ranlib',
AS => „jak”,
ASFLAGI => '',
ASCOM => '%AS %ASFLAGS %< -o %>',
LD => 'stary',
LDFLAGI => '',
PREFLIB => 'lib',
SUFLIB => '.a',
SUFLIBS => '.so:.a',
SUFOBJ => '.o',
ENV => { 'ŚCIEŻKA' => '/kosz:/ usr / bin' },

W systemach Win32 (Windows NT) następujące zmienne konstrukcyjne są zastępowane w pliku
domyślna:

CC => 'cl',
CFLAGS => '/nologo',
CCCOM => '%CC %CFLAGS %_IFLAGS /c %< /Fo%>',
CXXCOM => '%CXX %CXXFLAGS %_IFLAGS /c %< /Fo%>',
INCDIRPREFIX => '/I',
LINK => 'link',
LINKCOM => '%LINK %LDFLAGS /out:%> %< %_LDIRS %LIBS',
LINKMODULECOM => '%LD /r /o %> %<',
LIBDIRPREFIX => '/LIBPATH:',
AR => 'lib',
ARFLAGS => '/nologo ',
ARCOM => "%AR %ARFLAGS /wyjście:%> %<",
RANLIB => '',
LD => „link”,
LDFLAGS => '/nologo ',
PREFLIB => '',
SUFEXE => '.exe',
SUFLIB => '.lib',
SUFLIBS => '.dll:.lib',
SUFOBJ => '.obj',

Zmienne te są wykorzystywane przez różne metody związane ze środowiskiem, m.in
w szczególności każda metoda, która ostatecznie wywołuje polecenie zewnętrzne, zastąpi je
odpowiednio, zmienne do końcowego polecenia. Na przykład metoda „Obiekty” przyjmuje
pewną liczbę plików źródłowych i organizuje wyprowadzenie, jeśli to konieczne, odpowiedniego obiektu
akta. Na przykład:

Obiekty $env 'foo.c', 'bar.c';

Spowoduje to zorganizowanie produkcji, jeśli to konieczne, fuo.o i bar.o. Wywołane polecenie jest proste
`%CCCOM', które rozwija się poprzez podstawienie, do odpowiedniego wymaganego polecenia zewnętrznego
zbudować każdy obiekt. Zastanowimy się nad regułami zastępowania w ramach „Polecenie”
sposób, poniżej.

Zmienne konstrukcyjne są również wykorzystywane do innych celów. Na przykład „CPPPATH” to
używany do określenia rozdzielonej dwukropkami ścieżki katalogów dołączanych. To mają być
przekazywane do preprocesora C i są również wykorzystywane przez maszynę skanującą pliki C
określić zależności związane z kompilacją C. Zmienne zaczynające się od
podkreślenia, są tworzone różnymi metodami i zwykle powinny być uważane za „wewnętrzne”
zmienne. Na przykład, gdy wywoływana jest metoda wywołująca utworzenie obiektu
ze źródła C tworzona jest zmienna `_IFLAGS': odpowiada to przełącznikom `-I'
wymagane przez kompilator C do reprezentowania katalogów określonych przez `CPPPATH'.

Należy zauważyć, że dla dowolnego środowiska wartość zmiennej jest ustawiana raz, a następnie
nigdy nie resetuj (aby zmienić zmienną, musisz stworzyć nowe środowisko. Podano metody
do kopiowania istniejących środowisk w tym celu). Niektóre zmienne wewnętrzne, np
`_IFLAGS' są tworzone na żądanie, ale raz ustawione pozostają niezmienne przez cały okres istnienia
środowisko.

Zmienne `CFLAGS', `LDFLAGS' i `ARFLAGS' zapewniają miejsce na przekazywanie opcji do
odpowiednio kompilator, moduł ładujący i archiwizator. Mniej oczywiste, `INCDIRPREFIX'
zmienna określa ciąg opcji, który ma zostać dodany na początku każdego dołączenia
katalog, aby kompilator wiedział, gdzie znaleźć .h akta. Podobnie,
Zmienna `LIBDIRPREFIX' określa ciąg opcji, który ma zostać dodany na początku
każdy katalog, w którym linker powinien przeszukiwać biblioteki.

Inna zmienna, „ENV”, służy do określenia środowiska systemowego podczas wykonywania
polecenia zewnętrznego. Domyślnie jedyną ustawioną zmienną środowiskową jest „PATH”,
która jest ścieżką wykonania polecenia UNIX. Aby uzyskać najwyższą powtarzalność, powinieneś
naprawdę zorganizuj ustawienie własnej ścieżki wykonania na najwyższym poziomie Skonstruować plik (lub
być może poprzez import odpowiedniego pakietu konstrukcyjnego za pomocą polecenia Perla „use”). The
zmienne domyślne mają na celu oderwanie się od ziemi.

Interpolacja Budowa zmienne

Zmienne środowiskowe konstrukcji mogą być interpolowane w nazwach plików źródłowych i docelowych
poprzedzając nazwę zmiennej konstrukcyjnej znakiem `%'.

$env = nowe wady(
DESTDIR => 'programy',
SRCDIR => 'źródło',
);
Program $env '%DESTDIR/hello', '%SRCDIR/hello.c';

Rozwijanie zmiennych konstrukcyjnych jest rekurencyjne — to znaczy w pliku Nazwa(y) zostaną ponownie
rozszerzany do momentu, w którym nie można już dokonać żadnych podstawień. Jeśli zmienna konstrukcyjna nie jest
zdefiniowany w środowisku, wówczas zostanie zastąpiony ciąg zerowy.

Domyślnie Budowa metody

Lista domyślnych metod konstrukcji obejmuje:

Połączenia „nowy” konstruktor

„Nową” metodą jest konstruktor obiektowy Perla. Oznacza to, że nie jest wywoływany poprzez referencję
do istniejącego środowiska budowlanego odniesienie, ale raczej statycznie, używając nazwy
z Perla pakiet gdzie zdefiniowany jest konstruktor. Metodę wywołuje się w następujący sposób:

$env = nowe wady( );

Środowisko, które otrzymasz z powrotem, jest zaliczane do pakietu „wady”, co oznacza, że ​​tak będzie
powiązałem z nim domyślne metody opisane poniżej. Indywidualna konstrukcja
zmienne można zastąpić, podając pary nazwa/wartość na liście zastąpień. Zauważ to
aby zastąpić dowolną zmienną środowiskową polecenia (tj. cokolwiek pod `ENV'), będziesz musiał to zrobić
zastąpić je wszystkie. Możesz obejść tę trudność, używając metody „kopiuj” na pliku
istniejące środowisko budowlane.

Połączenia „klon” metoda

Metoda „clone” tworzy klon istniejącego środowiska konstrukcyjnego i może nim być
wywołać jak w poniższym przykładzie:

$env2 = $env1->klon( );

Można zapewnić zastąpienia w zwykły sposób, aby utworzyć środowisko inne niż środowisko
oryginalny. Jeśli chcesz po prostu nową nazwę dla tego samego środowiska (co może być pomocne, gdy
eksportowanie środowisk do istniejących komponentów), możesz po prostu użyć prostego przypisania.

Połączenia „skopiuj” metoda

Metoda „copy” wyodrębnia zewnętrznie zdefiniowane zmienne konstrukcyjne z pliku
środowisku i zwraca je jako listę par nazwa/wartość. Zastąpienia mogą być również
pod warunkiem, że w takim przypadku zastąpione wartości zostaną zwrócone, jeśli to konieczne. The
zwróconą listę można przypisać do skrótu, jak pokazano w prototypie poniżej, ale można to również zrobić
manipulować w inny sposób:

%env = $env1->kopiuj( );

Wartość `ENV', która sama jest skrótem, jest również kopiowana do nowego skrótu, więc może to być
zmieniany bez obawy, że wpłynie to na oryginalne środowisko. Na przykład, jeśli naprawdę
chcesz zastąpić tylko zmienną `PATH' w środowisku domyślnym, możesz to zrobić
Następujące:

%cons = nowe wady()->kopiuj();
$wady{ENV}{PATH} = " ";
$wady = nowe wady(%wady);

Spowoduje to pozostawienie wszystkiego innego, co może znajdować się w domyślnym środowisku wykonawczym
spokojny.

Połączenia „Zainstaluj” metoda

Metoda `Install' organizuje instalację określonych plików w określonym
informator. Instalacja jest zoptymalizowana: plik nie jest kopiowany, jeśli można go połączyć. Jeśli
nie jest to pożądane zachowanie, konieczne będzie użycie innej metody instalacji
plik. Nazywa się to następująco:

Zainstaluj $środowisko , ;

Należy pamiętać, że chociaż pliki do zainstalowania mogą mieć dowolną nazwę, tylko ostatni
składnik każdej nazwy jest używany dla zainstalowanej nazwy docelowej. Jeśli więc np
umówić się na montaż foo/bar in baz, spowoduje to utworzenie bar Plik w baz katalog (nie
foo/bar).

Połączenia „Zainstaluj jako” metoda

Metoda `InstallAs' porządkuje określone źródło filet(s) do zainstalowania jako
określony cel filet(S). Jako listę plików należy określić wiele plików. The
instalacja jest zoptymalizowana: plik nie jest kopiowany, jeśli można go połączyć. Jeśli to nie jest to
pożądane zachowanie, konieczne będzie użycie innej metody instalacji pliku. To jest
nazywany następująco:

`InstallAs' działa na dwa sposoby:

Instalacja pojedynczego pliku:

Zainstaluj jako $env TgtFile, SrcFile;

Instalacja wielu plików:

ZainstalujAs $env ['tgt1', 'tgt2'], ['src1', 'src2'];

Lub nawet jako:

@źródło = qw(źródło1 źródło2 źródło3);
@tgts = qw(tgt1 tgt2 tgt3);
ZainstalujAs $env [@tgts], [@srcs];

Zarówno lista docelowa, jak i źródłowa powinny mieć tę samą długość.

Połączenia „Cenny” metoda

Metoda „Precious” prosi przeciwników, aby wcześniej nie usuwali określonego pliku lub listy plików
budując je na nowo. Jest wywoływany jako:

Cenny ;

Jest to szczególnie przydatne w przypadku zezwalania na przyrostowe aktualizacje bibliotek lub debugowanie
pliki informacyjne, które są aktualizowane, a nie każdorazowo tworzone na nowo. Minusy nadal będą
usuń pliki, jeśli podana jest opcja `-r'.

Połączenia „Polecenie” metoda

Metoda „Polecenie” jest metodą przechwytującą, której można użyć do uporządkowania dowolnego zewnętrznego
polecenie, które należy wywołać w celu aktualizacji elementu docelowego. W przypadku tego polecenia plik docelowy i lista
zapewnione są wejścia. Dodatkowo dostępna jest linia poleceń konstrukcyjnych (lub linie) w formie pliku
ciąg znaków (w tym ciągu może znajdować się wiele poleceń rozdzielonych znakami new
linie). „Polecenie” nazywa się następująco:

Polecenie $środ , , ;

Cel jest zależny od określonej listy plików wejściowych, a dane wejściowe muszą
zostać pomyślnie zbudowany, w przeciwnym razie Wady nie będą próbowały zbudować celu.

W obrębie polecenia konstrukcyjnego może znajdować się dowolna zmienna ze środowiska konstrukcyjnego
wprowadzane poprzez poprzedzenie nazwy zmiennej konstrukcyjnej znakiem `%'. To jest rekurencyjne:
polecenie jest rozwijane do momentu, w którym nie można już dokonać żadnych podstawień. Jeśli konstrukcja
zmienna nie jest zdefiniowana w środowisku, wówczas zostanie zastąpiony ciąg pusty. A
podwojone `%%' zostanie zastąpione pojedynczym `%' w poleceniu konstrukcji.

Istnieje kilka pseudo zmiennych, które również zostaną rozwinięte:

%> Nazwa pliku docelowego (w poleceniu obejmującym wiele celów jest to zawsze pierwszy cel
wspomniany).

%0 To samo co `%>'.

%1, %2, ..., %9
Odnoszą się one odpowiednio do pierwszego do dziewiątego pliku wejściowego.

%< Pełny zestaw danych wejściowych. Jeśli którykolwiek z nich został użyty gdziekolwiek indziej w
bieżący wiersz poleceń (przez `%1', `%2' itd.), wówczas zostaną one usunięte z pliku
lista dostarczona przez `%<'. Rozważ następujące polecenie znalezione w pliku a Poborowy filet
test katalog:

Polecenie $env 'tgt', qw(foo bar baz), qq(
echo %< -i %1 > %>
echo %< -i %2 >> %>
echo %< -i %3 >> %>
);

If tgt wymaga aktualizacji, wówczas spowodowałoby to wykonanie pliku
następujące polecenia, zakładając, że nie ustalono żadnego ponownego mapowania dla pliku test
katalog:

echo test/test słupkowy/baz -i test/foo > test/tgt
echo test/foo test/baz -i test/bar >> test/tgt
echo test/foo test/bar -i test/baz >> test/tgt

Po dowolnej z powyższych pseudozmiennych może bezpośrednio następować jedna z poniższych
przyrostki umożliwiające wybranie części rozwiniętej nazwy ścieżki:

:a bezwzględna ścieżka do nazwy pliku
:b katalog plus nazwa pliku pozbawiona sufiksu
:d katalog
:f nazwa pliku
:s przyrostek nazwy pliku
:F nazwa pliku pozbawiona sufiksu

Kontynuując powyższy przykład, `%<:f' rozwinie się do `foo bar baz', a `%':d>
rozwiń do „testuj”.

Możliwe jest programowe przepisanie części polecenia poprzez załączenie jego części
pomiędzy `%[' i `%]'. Spowoduje to wywołanie zmiennej konstrukcyjnej nazwanej jako pierwsze słowo
ujęte w nawiasach jako odniesienie do kodu Perla; wyniki tego połączenia zostaną wykorzystane
aby zastąpić zawartość nawiasów w wierszu poleceń. Na przykład, biorąc pod uwagę
istniejący plik wejściowy o nazwie tgt.in:

@keywords = qw(foo bar baz);
$env = nowe wady(X_COMMA => sub { dołącz(",", @_) });
Polecenie $env 'tgt', 'tgt.in', qq(
echo '# Słowa kluczowe: %[X_COMMA @słowa kluczowe %]' > %>
kot %< >> %>
);

Spowoduje to wykonanie:

echo '# Słowa kluczowe: foo,bar,baz' > tgt
kot tgt.in >> tgt

Po podstawieniu ciągi białych znaków są konwertowane na pojedyncze odstępy i
początkowe i końcowe białe znaki są eliminowane. Dlatego wprowadzenie nie jest możliwe
Białe znaki o zmiennej długości w łańcuchach przekazywane do polecenia, bez uciekania się do niektórych
coś w rodzaju cytatu z powłoki.

Jeśli podano wielowierszowy ciąg poleceń, polecenia są wykonywane sekwencyjnie. Jeśli w ogóle
z poleceń zakończy się niepowodzeniem, wówczas żadne z pozostałych nie zostanie wykonane, a cel nie zostanie oznaczony jako
zaktualizowany, tj. nowy podpis nie jest przechowywany dla celu.

Zwykle, jeśli wszystkie polecenia powiodą się i zwrócą status zerowy (lub dowolną platformę-
wymagane jest określone wskazanie powodzenia), wówczas zapisywany jest nowy podpis dla
cel. Jeśli polecenie błędnie zgłosi sukces nawet po niepowodzeniu, oznacza to Wady
załóżmy, że plik docelowy utworzony za pomocą tego polecenia jest dokładny i aktualny.

Zakłada się, że pierwsze słowo każdego ciągu poleceń po rozwinięciu jest plikiem wykonywalnym
polecenie sprawdziło zmienną środowiskową `PATH' (która z kolei jest określona przez
zmienna konstrukcyjna „ENV”). Jeśli to polecenie zostanie znalezione na ścieżce, cel to zrobi
zależy od tego: polecenie zostanie zatem zbudowane automatycznie, jeśli zajdzie taka potrzeba. Jego
możliwe jest pisanie poleceń wieloczęściowych do niektórych powłok, oddzielonych średnikami. Tylko
jednak będzie zależeć od pierwszego słowa polecenia, więc jeśli napiszesz ciągi poleceń
w ten sposób musisz albo jawnie ustawić zależność (za pomocą metody „Zależy”), albo
upewnij się, że polecenie, którego używasz, jest poleceniem systemowym, zgodnie z oczekiwaniami
dostępny. Jeśli nie jest dostępny, oczywiście pojawi się błąd.

Jeśli jakiekolwiek polecenie (nawet jedno w poleceniu wielowierszowym) zaczyna się od `[perl]', pozostała część
tego wiersza poleceń zostanie oceniony przez działający Perl, a nie rozwidlony przez
powłoka. Jeśli wystąpi błąd podczas analizowania języka Perl lub jeśli wyrażenie Perl zwróci 0 lub
undef, polecenie zostanie uznane za zakończone niepowodzeniem. Na przykład tutaj jest proste
polecenie, które tworzy plik `foo' bezpośrednio z Perla:

$env = nowe wady();
Polecenie $env „foo”,
qq([perl] open(FOO,'>foo');print FOO "cześć\\n"; zamknij(FOO); 1);

Zauważ, że kiedy polecenie jest wykonywane, jesteś w tym samym pakiecie, co wtedy, gdy Skonstruować
or Poborowy plik został odczytany, więc możesz wywoływać funkcje Perla, które w nim zdefiniowałeś
Skonstruować or Poborowy plik, w którym pojawia się `Polecenie':

$env = nowe wady();
sub utwórz_plik {
mój $plik = przesunięcie;
open(PLIK, ">$plik");
wydrukuj PLIK „cześć\n”;
Zamknij plik);
1 wrócić;
}
Polecenie $env 'foo', "[perl] &create_file('%>')";

Ciąg Perla zostanie użyty do wygenerowania podpisu dla pliku pochodnego, więc jeśli
zmień ciąg, plik zostanie odbudowany. Zawartość wszelkich wywoływanych podprogramów,
jednakże nie są częścią podpisu, więc jeśli zmodyfikujesz wywoływany podprogram, taki jak
`create_file' powyżej, cel to zrobi nie zostać odbudowany. Ostrzeż użytkownika.

Wady zwykle wyświetlają polecenie przed jego wykonaniem. To zachowanie jest pomijane, jeśli
pierwszym znakiem polecenia jest `@'. Pamiętaj, że może być konieczne oddzielenie `@' od
nazwę polecenia lub zmień jej nazwę, aby `@cmd' nie wyglądało jak tablica w cudzysłowie Perla
operatory wykonujące interpolację:

# Pierwsza linia poleceń jest niepoprawna,
#, ponieważ „@cp” wygląda jak tablica
# do funkcji qq// Perla.
# Zamiast tego użyj drugiego formularza.
Polecenie $env „foo”, „foo.in”, qq(
@cp %< plik tymczasowy
@ plik tymczasowy cp %>
);

Jeśli w dowolnym miejscu rozwiniętego wiersza poleceń znajdują się znaki meta powłoki, takie jak `<',
`>', cudzysłowy lub średnik, wówczas polecenie zostanie faktycznie wykonane poprzez wywołanie a
powłoka. Oznacza to, że polecenie takie jak:

płyta foo

samo wykonanie zwykle zakończy się niepowodzeniem, ponieważ na ścieżce nie ma polecenia `cd'. Ale polecenie
strunowy:

płyta CD $<:d; tar cf $>:f $<:f

po rozwinięciu nadal będzie zawierać średnik metaznaku powłoki, a powłoka będzie
wywoływany w celu interpretacji polecenia. Ponieważ `cd' jest interpretowane przez tę podpowłokę, polecenie
zostanie wykonany zgodnie z oczekiwaniami.

Aby określić polecenie z wieloma celami, możesz podać odwołanie do listy
cele. W Perlu odwołanie do listy można utworzyć, umieszczając listę w nawiasach kwadratowych.
Stąd następujące polecenie:

Polecenie $env ['foo.h', 'foo.c'], 'foo.template', q(
generacja %1
);

można użyć w przypadku, gdy polecenie `gen' tworzy dwa pliki, obydwa foo.h i foo.c.

Połączenia „Obiekty” metoda

Metoda `Objects' organizuje utworzenie plików obiektowych odpowiadających określonemu
pliki źródłowe. Jest wywoływany w sposób pokazany poniżej:

@files = Obiekty $środ ;

W systemie Unix pliki źródłowe kończące się na .s i .c są obecnie obsługiwane i zostaną skompilowane
na nazwę tego samego pliku kończącą się na .o. Domyślnie wszystkie pliki są tworzone poprzez wywołanie
polecenie zewnętrzne będące wynikiem rozwinięcia zmiennej konstrukcyjnej `CCCOM' o
`%<' i `%>' ustawione odpowiednio na pliki źródłowe i obiektowe (patrz metoda `Command'
w celu uzyskania szczegółów rozszerzenia). Zmienna `CPPPPATH' jest również używana podczas skanowania plików źródłowych
dla zależności. Jest to rozdzielona dwukropkami lista nazw ścieżek, używana również do tworzenia
zmienna konstrukcyjna `_IFLAGS', która będzie zawierać odpowiednią listę -`I'
opcje kompilacji. Wszelkie względne nazwy ścieżek w `CPPPATH' są interpretowane względnie
do katalogu, w którym utworzono powiązane środowisko konstrukcyjne (absolute
można również używać nazw najwyżej względnych). Ta zmienna jest używana przez `CCCOM'. Zachowanie
tego polecenia można modyfikować poprzez zmianę dowolnej interpolowanej zmiennej
do `CCCOM', na przykład `CC', `CFLAGS' i pośrednio `CPPPATH'. Jest to również możliwe
zastąp samą wartość `CCCOM'. Dla wygody plik ten zwraca listę
nazwy plików obiektów.

Połączenia „Program” metoda

Metoda `Program' organizuje połączenie określonego programu z określonym obiektem
akta. Wywołuje się go w następujący sposób:

Program $środ , ;

Do nazwy programu zostanie dodana wartość zmiennej konstrukcyjnej `SUFEXE' (wg
domyślnie `.exe' w systemach Win32, nic w systemach Unix), jeśli przyrostek nie jest jeszcze
prezent.

Zamiast plików obiektowych można podać pliki źródłowe — będzie to metoda `Objects'
wywoływany w celu zorganizowania konwersji wszystkich plików na pliki obiektowe, a tym samym wszystkie pliki
powyższe obserwacje dotyczące metody „Obiekty” odnoszą się również do tej metody.

Faktyczne połączenie programu będzie obsługiwane przez zewnętrzne polecenie, które w rezultacie zostanie wykonane
z rozwinięcia zmiennej konstrukcyjnej `LINKCOM', z `%<' ustawionym na pliki obiektowe
być połączone (w podanej kolejności), a `%>' ustawione na cel (zobacz metodę `Command'
w celu uzyskania szczegółów rozszerzenia). Użytkownik może ustawić dodatkowe zmienne w konstrukcji
środowisko, w tym `LINK', w celu zdefiniowania programu, którego należy używać do łączenia, `LIBPATH', a
rozdzielona dwukropkami lista ścieżek przeszukiwania bibliotek, do użycia ze specyfikacjami bibliotek
Nasz formularz -llibi `LIBS', określające listę bibliotek, z którymi można się połączyć (w obu plikach -llib
formie lub po prostu jako nazwy ścieżek. Interpretowane są względne nazwy ścieżek w `LIBPATH' i `LIBS'
względem katalogu, w którym tworzone jest powiązane środowisko konstrukcyjne
(można również używać nazw bezwzględnych i top-względnych). Wady ustawiają się automatycznie
zależności od bibliotek wymienionych w `LIBS': te biblioteki zostaną zbudowane wcześniej
polecenie jest powiązane.

Połączenia „Biblioteka” metoda

Metoda `Library' organizuje utworzenie określonej biblioteki z określonego obiektu
akta. Wywołuje się go w następujący sposób:

Biblioteka $środ , ;

Do nazwy biblioteki będzie dołączona wartość zmiennej konstrukcyjnej `SUFLIB' (wg
domyślnie `.lib' w systemach Win32, `.a' w systemach Unix), jeśli przyrostek nie jest jeszcze
prezent.

Zamiast plików obiektowych można podać pliki źródłowe — będzie to metoda `Objects'
wywoływany w celu zorganizowania konwersji wszystkich plików na pliki obiektowe, a tym samym wszystkie pliki
powyższe obserwacje dotyczące metody „Obiekty” odnoszą się również do tej metody.

Faktyczne utworzenie biblioteki będzie obsługiwane przez zewnętrzne polecenie, które spowoduje
z rozwinięcia zmiennej konstrukcyjnej `ARCOM', z `%<' ustawionym na elementy biblioteki (w
w podanej kolejności) i `%>' do biblioteki, która ma zostać utworzona (zobacz metodę `Command' dla
szczegóły rozbudowy). Użytkownik może ustawić zmienne w środowisku konstrukcyjnym, które to zrobią
mieć wpływ na działanie polecenia. Należą do nich `AR', program do archiwizacji,
`ARFLAGS', za pomocą którego można modyfikować flagi nadawane programowi określonemu przez `AR',
i `RANLIB', nazwa programu generującego indeks archiwum, jeśli jest to konieczne (jeśli określony
need nie wymaga tej drugiej funkcjonalności, wówczas należy przedefiniować „ARCOM” tak, aby nie wymagał
odwołanie do „RANLIB”).

Metoda „Biblioteka” umożliwia określenie tej samej biblioteki w wielu metodach
modły. Wszystkie obiekty przyczyniające się ze wszystkich wywołań (które mogą pochodzić z
różne katalogi) są łączone i generowane za pomocą jednego polecenia archiwizacji. Notatka,
jednak jeśli przytniesz kompilację tak, aby określona była tylko część biblioteki, to tylko
ta część biblioteki zostanie wygenerowana (reszta zniknie!).

Połączenia „Moduł” metoda

Metoda `Module' jest kombinacją metod `Program' i `Command'. Zamiast
generując bezpośrednio program wykonywalny, to polecenie pozwala określić własny
polecenie, aby faktycznie wygenerować moduł. Metodę wywołuje się w następujący sposób:

Moduł $środ , , ;

To polecenie jest przydatne w przypadkach, gdy chcesz tworzyć na przykład dynamicznie
załadowane moduły lub statycznie połączone biblioteki kodu.

Połączenia „Zależy” metoda

Metoda „Zależy” pozwala określić dodatkowe zależności dla celu. To jest
wywołany w następujący sposób:

Zależy $środ , ;

Może to być czasami przydatne, szczególnie w przypadkach, gdy nie istnieje żaden skaner (lub jest
zapisywalny) dla określonych typów plików. Zwykle obliczane są zależności
automatycznie z kombinacji jawnych zależności skonfigurowanych przez metodę
wywołanie lub poprzez skanowanie plików źródłowych.

Zestaw identycznych zależności dla wielu celów można określić za pomocą odwołania do
listę celów. W Perlu odwołanie do listy można utworzyć, umieszczając listę w kwadracie
nawiasy. Stąd następujące polecenie:

Zależy $env ['foo', 'bar'], 'plik_wejściowy_1', 'plik_wejściowy_2';

określa, że ​​zarówno bla i bar zależą od wymienionych plików wejściowych.

Połączenia „Ignoruj” metoda

Metoda `Ignore' pozwala jawnie ignorować zależności, jakie Cons na jej podstawie wnioskuje
własny. Wywołuje się go w następujący sposób:

Ignorować ;

Można tego użyć, aby uniknąć ponownej kompilacji z powodu zmian w systemowych plikach nagłówkowych lub
narzędzia, o których wiadomo, że nie wpływają na wygenerowane cele.

Jeśli na przykład program jest wbudowany w katalog zamontowany w systemie NFS na wielu systemach, to
mieć różne kopie stdio.h, różnice wpłyną na podpisy wszystkich
cele pochodne zbudowane z plików źródłowych, które `#include '. To spowoduje wszystko
cele te należy odbudować przy zmianie systemów. Jeśli nie jest to pożądane zachowanie,
następnie następujący wiersz usunie zależności w pliku stdio.h file:

Ignoruj ​​'^/usr/include/stdio\.h$';

Zauważ, że argumenty metody `Ignore' są wyrażeniami regularnymi, a więc wyjątkowymi
znaki muszą być zmienione i możesz chcieć zakotwiczyć początek lub koniec
wyrażenie zawierające znaki `^' lub `$'.

Połączenia „Sól” metoda

Metoda „Salt” dodaje stałą wartość do obliczeń podpisu dla każdego wyprowadzenia
plik. Wywołuje się go w następujący sposób:

Sól $string;

Zmiana wartości Salt wymusi całkowitą przebudowę każdego pochodnego pliku. To może być
używane do wymuszania przebudowy w określonych pożądanych okolicznościach. Na przykład,

Sól `uname -s`;

Wymusiłoby to całkowitą przebudowę każdego pliku pochodnego przy każdym włączeniu systemu operacyjnego
którym wykonywana jest kompilacja (zgodnie z informacją `uname -s').

Połączenia „Użyj pamięci podręcznej” metoda

Metoda `UseCache' instruuje Consa, aby utrzymywał pamięć podręczną plików pochodnych, które mają być udostępniane
pomiędzy oddzielnymi drzewami kompilacji tego samego projektu.

UseCache("pamięć podręczna/ ") ⎪⎪ warn("Nie znaleziono katalogu pamięci podręcznej");

Połączenia `Ścieżka Źródłowa' metoda

Metoda `SourcePath' zwraca rzeczywistą nazwę ścieżki źródłowej pliku, w przeciwieństwie do metody
nazwa ścieżki w katalogu kompilacji. Wywołuje się go w następujący sposób:

$ścieżka = Ścieżka źródłowa ;

Połączenia „Ścieżka wad” metoda

Metoda `ConsPath' zwraca wartość true, jeśli podana ścieżka jest plikiem, który można wyprowadzić, i zwraca wartość true
undef (false) w przeciwnym razie. Wywołuje się go w następujący sposób:

$result = Ścieżka wad ;

Połączenia „Podział ścieżki” metoda

Metoda `SplitPath' wyszukuje wiele nazw ścieżek w ciągu znaków oddzielonych domyślnie
separator ścieżki dla systemu operacyjnego („:” w systemach UNIX, „;” w Windows NT) oraz
zwraca w pełni kwalifikowane nazwy. Wywołuje się go w następujący sposób:

@ścieżki = SplitPath ;

Metoda `SplitPath' skonwertuje nazwy z przedrostkiem '#' na odpowiednią wersję najwyższego poziomu
name (bez „#”) i skonwertuje nazwy względne na nazwy najwyższego poziomu.

Połączenia „Ścieżka katalogu” metoda

Metoda `DirPath' zwraca ścieżkę kompilacji Nazwa(s) katalogu lub listy katalogów.
Wywołuje się go w następujący sposób:

$cwd = ścieżka katalogu ;

Najpopularniejszym zastosowaniem metody `DirPath' jest:

$cwd = ścieżka katalogu '.';

aby pobrać ścieżkę do bieżącego katalogu spółki zależnej Poborowy plik.

Połączenia „Ścieżka pliku” metoda

Metoda `FilePath' zwraca ścieżkę kompilacji Nazwa(y) pliku lub listy plików. To jest
wywołany w następujący sposób:

$plik = ścieżka pliku ;

Połączenia „Pomoc” metoda

Metoda `Help' określa tekst pomocy, który będzie wyświetlany, gdy użytkownik wywoła `cons
-H'. Można to wykorzystać do dostarczenia dokumentacji konkretnych celów, wartości i kompilacji
opcje itp. dla drzewa kompilacji. Wywołuje się go w następujący sposób:

Pomoc ;

Metodę `Help' można wywołać tylko raz i zazwyczaj powinna być określona w górnym
poziom Skonstruować plik.

Rozsuwalny Wady

Nadrzędny Budowa zmienne

Istnieje kilka sposobów rozbudowy Wad, różniących się stopniem trudności. Najprostszy
metoda polega na zdefiniowaniu własnego środowiska konstrukcyjnego w oparciu o środowisko domyślne,
ale zmodyfikowane w celu odzwierciedlenia Twoich konkretnych potrzeb. Często będzie to wystarczające w przypadku programów opartych na języku C
Aplikacje. Możesz użyć konstruktora `new' oraz metod `clone' i `copy' do
tworzyć środowiska hybrydowe. Zmiany te mogą być całkowicie przejrzyste dla instrumentu bazowego
Poborowy akta.

Dodawanie nowa metody

W przypadku nieco bardziej wymagających zmian możesz dodać nowe metody do „wad”
pakiet. Oto przykład bardzo prostego rozszerzenia „InstallScript”, które instaluje plik
tcl w żądanej lokalizacji, ale najpierw edytuje skrypt, aby odzwierciedlić platformę-
ścieżka zależna, którą należy zainstalować w skrypcie:

# cons::InstallScript — Utwórz wersję powłoki zależną od platformy
# skrypt, zastępując ciąg ``#!twoja-ścieżka-tutaj'' specyficznym dla platformy
# ścieżka $BIN_DIR.

wady::InstallScript {
mój ($env, $dst, $src) = @_;
Polecenie $env $dst, $src, qq(
sed s+twoja-ścieżka-tutaj+$BIN_DIR+ %< > %>
chmod oug+x %>
);
}

Zauważ, że ta metoda jest zdefiniowana bezpośrednio w pakiecie `cons' (poprzez dodanie prefiksu nazwy
z „wadami::”). Zmiana dokonana w ten sposób będzie globalnie widoczna dla wszystkich środowisk,
i można go wywołać jak w poniższym przykładzie:

Skrypt instalacyjny $env "$BIN/foo", "foo.tcl";

Dla niewielkiej poprawy ogólności zmienną `BINDIR' można przekazać jako
argument lub pobrany ze środowiska konstrukcyjnego - jako `%BINDIR'.

Nadrzędny metody

Zamiast dodawać metodę do przestrzeni nazw „cons”, możesz zdefiniować nowy pakiet
który dziedziczy istniejące metody z pakietu `cons' i zastępuje lub dodaje inne. Ten
można tego dokonać za pomocą mechanizmów dziedziczenia Perla.

Poniższy przykład definiuje nowy pakiet `cons::switch', który zastępuje standard
Metoda „biblioteczna”. Przesłonięta metoda buduje połączone moduły biblioteczne, a nie bibliotekę
archiwa. Udostępniono nowy konstruktor. Środowiska utworzone za pomocą tego konstruktora będą
mieć nową metodę biblioteczną; inni tego nie zrobią.

wady pakietu::switch;
ROZPOCZNIJ {@ISA = 'wady'}

sub nowy {
Zmiana;
pobłogosław nowe wady(@_);
}

podbiblioteka {
my($środowisko) = przesunięcie;
my($lib) = przesunięcie;
my(@objs) = Obiekty $env @_;
Polecenie $env $lib, @objs, q(
%LD -r %LDFLAGS %< -o %>
);
}

Funkcjonalność tę można wywołać w następujący sposób:

$env = nowe wady::switch(@overrides);
...
Biblioteka $env 'lib.o', 'foo.c', 'bar.c';

Przywoływanie Wady

Polecenie `cons' jest zwykle wywoływane z katalogu głównego drzewa kompilacji. A Skonstruować filet
musi istnieć w tym katalogu. Jeśli użyto argumentu `-f', wówczas alternatywny Skonstruować
można użyć pliku (i ewentualnie alternatywnego katalogu głównego, ponieważ `cons' spowoduje cd do Skonstruować
katalog zawierający plik).

Jeżeli `cons' zostanie wywołane z elementu podrzędnego katalogu głównego drzewa kompilacji z argumentem `-t', to
przejdzie w górę hierarchii katalogów, szukając pliku Skonstruować plik. (Alternatywna nazwa może
nadal być określone z `-f'.) Cele podane w wierszu poleceń zostaną zmodyfikowane
być w stosunku do odkrytego Skonstruować plik. Na przykład z katalogu zawierającego
najwyższy poziom Skonstruować pliku, wykonaj następujące wywołanie:

% cd libfoo/podkatalog
% wad -t cel

jest dokładnie odpowiednikiem:

% wad libfoo/subdir/target

Jeśli w hierarchii katalogów określono jakieś „domyślne” cele Skonstruować or
Poborowy pliki, tylko domyślne cele w katalogu lub poniżej, z którego pochodzi `cons -t'
został wywołany, zostanie zbudowany.

Polecenie wywołuje się w następujący sposób:

Cons --

gdzie argumenty może być dowolnym z poniższych, w dowolnej kolejności:

cel Zbuduj określony cel. Jeśli cel jest katalogiem, a następnie rekurencyjnie go zbuduj
wszystko w tym katalogu.

+wzór Ogranicz Poborowy pliki są brane pod uwagę tylko te, które pasują wzorzec, który jest
wyrażenie regularne Perla. Akceptowanych jest wiele argumentów `+'.

Nazwa=
Zestawy Nazwa cenić val w hashu `ARG' przeszedł na najwyższy poziom Skonstruować plik.

`-cc' Pokazuje polecenie, które zostałoby wykonane podczas pobierania z pamięci podręcznej. NIE
wyświetlana jest informacja, że ​​plik został pobrany; jest to przydatne
generowanie dzienników kompilacji, które można porównać z prawdziwymi dziennikami kompilacji.

`-cd' Wyłącza całe buforowanie. Nie pobieraj z pamięci podręcznej ani nie opróżniaj do pamięci podręcznej.

`-cr' Buduj zależności w losowej kolejności. Jest to przydatne podczas budowania wielu obiektów
podobne drzewa z włączonym buforowaniem.

`-cs' Synchronizuje istniejące cele kompilacji, które okazały się aktualne, z pamięcią podręczną.
Jest to przydatne, jeśli buforowanie zostało wyłączone za pomocą opcji -cc lub zostało niedawno włączone
z UseCachem.

`-d' Włącz debugowanie zależności.

`-f'
Użyj określonego pliku zamiast Skonstruować (ale najpierw zmień na zawierający
katalog filet).

`-h' Wyświetla komunikat pomocy lokalny dla bieżącej kompilacji, jeśli taki jest zdefiniowany, i kończy.

`-k' Kontynuuj po błędach tak daleko, jak to możliwe.

„-o”
Przeczytaj plik zastępujący filet.

`-p' Pokaż produkty budowlane w określonych drzewach. Nie podjęto żadnej próby kompilacji.

`-pa' Wyświetla produkty budowlane i powiązane z nimi akcje. Nie podjęto żadnej próby kompilacji.

`-pw' Pokaż produkty i miejsce ich definicji. Nie podjęto żadnej próby kompilacji.

`-q' Nie mów szczegółowo o instalowaniu i usuwaniu obiektów docelowych.

`-r' Usuń produkty budowlane powiązane z . Nie podjęto żadnej próby kompilacji.

`-R'
Szukaj plików w repo. Wielokrotność -R repo katalogi są przeszukiwane w
zamówienie określone.

`-t' Przechodzi w górę hierarchii katalogów w poszukiwaniu Skonstruować plik, jeśli taki nie istnieje
w bieżącym katalogu. Cele zostaną zmodyfikowane tak, aby były względne
Skonstruować plik.

`-v' Pokaż wersję ,,wady" i kontynuuj przetwarzanie.

`-V' Pokaż wersję ,,wady" i wyjdź.

`-wf'
Zapisz wszystkie brane pod uwagę nazwy plików filet.

`-x' Wyświetla komunikat pomocy podobny do tego i kończy działanie.

oraz argumenty konstrukcyjne mogą być dowolnymi argumentami, które chcesz przetworzyć w pliku Skonstruować plik.
Należy pamiętać, że powinno być -- oddzielając argumenty przeciw i argumenty ty
chcesz przetworzyć w Skonstruować plik.

Przetwarzanie argumenty konstrukcyjne można to zrobić za pomocą dowolnego standardowego pakietu, takiego jak Getopt lub jego
warianty lub dowolny pakiet zdefiniowany przez użytkownika. minusy przejdzie w argumenty konstrukcyjne as @agawa i
nie będzie próbował interpretować niczego po --.

% cons -R /usr/local/repository -d os=solaris +sterownik -- -c test -f DEBUGOWANIE

przekazałby następujące informacje do cons

-R /usr/local/repository -d os=solaris +sterownik

i następne, na najwyższy poziom Skonstruować plik jako @agawa

-c test -f DEBUGOWANIE

Zauważ, że `cons -r.' jest równoważne pełnemu rekurencyjnemu „make clean”, ale nie wymaga
wsparcie w Skonstruować plik lub dowolny Poborowy akta. Jest to najbardziej przydatne, jeśli tak jest
kompilowanie plików do katalogów źródłowych (jeśli oddzielisz plik budować i eksport katalogi,
wtedy możesz po prostu usunąć katalogi).

Opcje `-p', `-pa' i `-pw' są niezwykle przydatne jako pomoc w czytaniu
skrypty lub ich debugowanie. Jeśli chcesz wiedzieć, jaki skrypt instaluje eksport/include/foo.h,
na przykład po prostu wpisz:

% wad -pw eksport/include/foo.h

Korzystanie z i pisanie zależność skanery

QuickScan umożliwia skonfigurowanie prostych skanerów niezależnych od celu dla plików źródłowych. Tylko
jeden skaner QuickScan może być powiązany z dowolnym plikiem źródłowym i środowiskiem.

QuickScan jest wywoływany w następujący sposób:

QuickScan CONSENV CODEREF, NAZWA PLIKU [, ŚCIEŻKA]

Oczekuje się, że podprogram, do którego odwołuje się CODEREF, zwróci listę zawartych nazw plików
bezpośrednio przez PLIK. Te nazwy plików zostaną z kolei przeskanowane. Opcjonalny argument PATH
udostępnia ścieżkę wyszukiwania w celu znalezienia NAZWY PLIKU i/lub plików zwróconych przez użytkownika
podprogram. PATH może być odniesieniem do tablicy nazw katalogów wyszukiwania lub a
ciąg nazw oddzielonych znakiem systemowego separatora („:” w systemach UNIX, „;” w
WindowsNT).

Podprogram jest wywoływany raz dla każdej linii w pliku, przy czym $_ jest ustawione na bieżącą linię.
Jeśli podprogram musi sprawdzić dodatkowe linie lub cały plik,
wówczas może je sam odczytać z uchwytu pliku SCAN. Może również zakończyć pętlę, jeśli
wie, że nie są już dostępne żadne dalsze informacje, zamykając uchwyt pliku.

Niezależnie od tego, czy podana jest ścieżka wyszukiwania, program QuickScan najpierw próbuje wyszukać plik
względem bieżącego katalogu (dla pliku najwyższego poziomu dostarczanego bezpośrednio do QuickScan),
lub z katalogu zawierającego plik, który odwołuje się do pliku. To nie jest bardzo
ogólnie, ale wydaje się wystarczająco dobre – zwłaszcza jeśli masz luksus pisania własnych
narzędzia i może w standardowy sposób kontrolować wykorzystanie ścieżki wyszukiwania. Wreszcie,
ścieżka wyszukiwania jest obecnie oddzielona dwukropkami. To może nie uszczęśliwić obozu NT.

Oto prawdziwy przykład zaczerpnięty z: Skonstruować plik tutaj:

wady::SMFgen {
my($env, @tables) = @_;
foreach $t (@tables) {
$env->QuickScan(sub { /\b\S*?\.smf\b/g }, "$t.smf",
$env->{SMF_INCLUDE_PATH});
$env->Polecenie(
["$t.smdb.cc","$t.smdb.h","$t.snmp.cc","$t.ami.cc", "$t.http.cc"],
"$t.smf",
q(
smfgen %(%SMF_INCLUDE_OPT %)%
)
);
}
}

[PAMIĘTAJ, że formularze `$env->QuickScan ...' i `$env->Command ...' nie powinny być
konieczne, ale z jakiegoś powodu wymagane dla tego konkretnego wywołania. To się pojawia
być błędem w Perlu lub nieporozumieniem z mojej strony; ten styl wywołania tego nie robi
zawsze wydają się konieczne.]

Spowoduje to znalezienie wszystkich nazw formularza .smf w pliku. Zwróci nazwy, nawet jeśli
można je znaleźć w komentarzach, ale to jest w porządku (mechanizm wybacza dodatkowe pliki;
są one po prostu ignorowane przy założeniu, że brakujący plik zostanie zauważony, gdy plik
program (w tym przykładzie smfgen) jest faktycznie wywoływany).

Skaner jest wywoływany dla danego pliku źródłowego tylko wtedy, gdy jest potrzebny jakieśmu celowi w pliku
drzewo. Jest on wywoływany tylko raz dla danego pliku źródłowego.

Oto inny sposób zbudowania tego samego skanera. Ten używa wyraźnego odniesienia do kodu,
a także (w tym przypadku niepotrzebnie) czyta cały sam plik:

sub myscan {
mój(@zawiera);
zrobić {
push(@zawiera, /\b\S*?\.smf\b/g);
} chwila ;
@zawiera
}

Należy pamiętać, że kolejność pętli jest odwrotna i na końcu znajduje się test pętli. To jest
ponieważ pierwsza linijka jest już dla Ciebie przeczytana. Skaner ten można podłączyć do źródła
plik przez:

QuickScan $env \myscan, "$_.smf";

WSPIERAJ ROLNICZE PROPOZYCJE

Wady są utrzymywane przez społeczność użytkowników. Aby zapisać się wyślij e-mail na adres przeciw-dyskutuj-
[email chroniony] z ciałem subskrybuj.

Prosimy o zgłaszanie wszelkich sugestii poprzez [email chroniony] lista mailingowa.

Korzystaj z wad online, korzystając z usług onworks.net