cons - Online sa Cloud

PROGRAMA:

NAME

Cons - Isang Software Construction System

DESCRIPTION

Isang gabay at sanggunian para sa bersyon 2.2.0

Copyright (c) 1996-2000 Libreng Software Foundation, Inc.

Ang program na ito ay libreng software; maaari mo itong muling ipamahagi at/o baguhin ito sa ilalim ng mga tuntunin ng
ang GNU General Public License na inilathala ng Free Software Foundation; alinman
bersyon 2 ng Lisensya, o (sa iyong opsyon) anumang mas bagong bersyon.

Ang program na ito ay ipinamahagi sa pag-asa na ito ay magiging kapaki-pakinabang, ngunit WALANG ANUMANG WARRANTY;
nang walang kahit na ipinahiwatig na warranty ng MERCHANTABILITY o FITNESS FOR A PARTICULAR PURPOSE.
Tingnan ang GNU General Public License para sa higit pang mga detalye.

Dapat ay nakatanggap ka ng kopya ng GNU General Public License kasama ng programang ito;
tingnan ang file na COPYING. Kung hindi, sumulat sa Free Software Foundation, Inc., 59 Temple
Lugar - Suite 330, Boston, MA 02111-1307, USA.

pagpapakilala

Kahinaan ay isang sistema para sa pagbuo, pangunahin, software, ngunit medyo naiiba sa
nakaraang mga sistema ng pagbuo ng software. Cons ay dinisenyo mula sa simula hanggang sa pakikitungo
madali sa pagbuo ng software na kumalat sa maraming mga direktoryo ng pinagmulan. Cons
pinapadali ang paggawa ng mga script ng build na simple, naiintindihan at napanatili.
Tinitiyak ng mga kahinaan na ang kumplikadong software ay madali at tumpak na mai-reproducible.

Gumagamit ang Cons ng ilang mga diskarte upang magawa ang lahat ng ito. Ang mga script ng konstruksiyon ay makatarungan
Perl script, ginagawa silang parehong madaling maunawaan at napaka-flexible. Pandaigdigang saklaw ng
ang mga variable ay pinapalitan ng mekanismo ng pag-import/pag-export para sa pagbabahagi ng impormasyon sa pagitan
script, makabuluhang pagpapabuti ng pagiging madaling mabasa at mapanatili ng bawat script.
konstruksyon kapaligiran ay ipinakilala: ito ang mga Perl na bagay na kumukuha ng
impormasyong kinakailangan para sa pagkontrol sa proseso ng pagbuo. Maramihang mga kapaligiran ang ginagamit
kapag ang iba't ibang semantika ay kinakailangan para sa pagbuo ng mga produkto sa build tree. Cons
nagpapatupad ng awtomatikong pagsusuri sa dependency at ginagamit ito para sa buong mundo na pagkakasunud-sunod
magtayo. Ang mga variant na build ay madaling ginawa mula sa isang punong pinagmulan. Matalinong pagbuo
Posible ang subsetting, kapag nagtatrabaho sa mga lokal na pagbabago. Maaaring i-setup ang mga override sa
madaling i-override ang mga tagubilin sa pagbuo nang hindi binabago ang anumang mga script. MD5 cryptographic
lagda ay nauugnay sa mga nagmula na file, at ginagamit upang tumpak na matukoy kung
ang isang naibigay na file ay kailangang muling itayo.

Habang inaalok ang lahat ng nasa itaas, at higit pa, ang Cons ay nananatiling simple at madaling gamitin. Ito ay,
sana, maging malinaw habang binabasa mo ang natitirang bahagi ng dokumentong ito.

Bakit cons? Bakit hindi Gumawa?

Ang kahinaan ay a gumawa kapalit. Sa mga sumusunod na talata, titingnan natin ang ilan sa mga
hindi kanais-nais na mga katangian ng make--at karaniwang build environment batay sa make--na
nag-udyok sa pagbuo ng Cons.

Magtayo kaguluhan

Ang mga tradisyunal na sistema na nakabatay sa paggawa ng anumang laki ay malamang na maging kumplikado. Ang orihinal na gawa
ang utility at ang mga derivatives nito ay nag-ambag sa tendensiyang ito sa maraming paraan. Gumawa ay
hindi mahusay sa pakikitungo sa mga system na nakakalat sa maraming mga direktoryo. Iba't ibang gawain-
ang mga paligid ay ginagamit upang malampasan ang kahirapan na ito; ang karaniwang pagpipilian ay para sa make to invoke
mismong recursively para sa bawat sub-directory ng isang build. Ito ay humahantong sa kumplikadong code, sa
na kadalasang hindi malinaw kung paano itinatakda ang isang variable, o kung ano ang epekto sa setting ng isang variable
magkakaroon sa build bilang isang buo. Ang make scripting language ay unti-unting pinalawig
upang magbigay ng higit pang mga posibilidad, ngunit ang mga ito ay higit na nagsilbi sa kalat ng isang na
overextended na wika. Kadalasan, ginagawa ang mga build sa maraming pass para makapagbigay
naaangkop na mga produkto mula sa isang direktoryo patungo sa isa pang direktoryo. Ito ay kumakatawan sa isang karagdagang
pagtaas sa pagiging kumplikado ng pagbuo.

Magtayo kakayahang mabuo

Ang bane ng lahat ng gumagawa ay palaging ang tamang paghawak ng mga dependencies. Kadalasan, isang
Ang pagtatangkang gawin ang isang makatwirang trabaho ng mga dependencies sa loob ng iisang direktoryo, ngunit hindi
malubhang pagtatangka ay ginawa upang gawin ang trabaho sa pagitan ng mga direktoryo. Kahit na ang mga dependencies ay
gumagana nang tama, umasa sa isang simpleng paghahambing ng time stamp upang matukoy kung
ang isang file ay hindi napapanahon na may kinalaman sa mga dependent nito ay hindi, sa pangkalahatan, ay sapat para sa
pagtukoy kung kailan dapat muling makuha ang isang file. Kung ang isang panlabas na aklatan, halimbawa, ay
itinayong muli at pagkatapos ay ``na-snapped'' sa lugar, ang mga timestamp sa mga bagong likhang file nito ay maaaring
mas maaga kaysa sa huling lokal na build, dahil ito ay itinayo bago pa ito makita.

baryante gagawa

Ang Make ay nagbibigay lamang ng mga limitadong pasilidad para sa paghawak ng mga variant na build. Sa paglaganap
ng mga platform ng hardware at ang pangangailangan para sa debuggable kumpara sa na-optimize na code, ang kakayahang
madaling gawin ang mga variant na ito ay mahalaga. Higit sa lahat, kung ang mga variant ay ginawa, ito
ay mahalaga upang magawang paghiwalayin ang mga variant o upang magawang kopyahin ang
orihinal o variant sa kalooban. Sa paggawa, napakahirap paghiwalayin ang mga build
maramihang mga build na direktoryo, hiwalay sa pinagmulan. At kung ang pamamaraang ito ay hindi ginagamit,
halos imposible ding magarantiya sa anumang oras kung saang variant naroroon
ang puno, nang hindi gumagamit ng kumpletong muling pagtatayo.

Mga Repository

Ang Make ay nagbibigay lamang ng limitadong suporta para sa pagbuo ng software mula sa code na umiiral sa a
istraktura ng direktoryo ng sentral na imbakan. Ang tampok na VPATH ng GNU make (at ilang iba pa
gumawa ng mga pagpapatupad) ay inilaan upang ibigay ito, ngunit hindi gumagana tulad ng inaasahan: ito
masyadong maagang binabago ang path ng target na file sa pangalan ng VPATH sa pagsusuri nito, at samakatuwid
hinahanap ang lahat ng mga dependency sa direktoryo ng VPATH. Upang matiyak ang tamang pag-unlad
build, mahalagang makagawa ng file sa isang lokal na direktoryo ng build at magkaroon
anumang mga file sa isang imbakan ng code (isang direktoryo ng VPATH, sa mga tuntunin) na nakadepende sa lokal
ang file ay muling itinayong muli. Hindi ito posible sa VPATH, nang walang coding ng marami
kumplikadong kaalaman sa repository nang direkta sa makefiles.

nag-iingat it simple

Ang ilan sa mga paghihirap sa paggawa ay nabanggit sa itaas. Dito at kasunod
mga seksyon, ipakikilala namin ang Mga Kahinaan at ipapakita kung paano tinutugunan ang mga isyung ito.

Perl script

Cons ay Perl-based. Iyon ay, Cons script--konskript at Tayuan mga file, ang katumbas
sa Makefile or makefile--lahat ay nakasulat sa Perl. Nagbibigay ito ng agarang benepisyo: ang
pamilyar ang wika para sa pagsulat ng mga script. Kahit na hindi ka nagkataon na isang Perl
programmer, nakakatulong na malaman na ang Perl ay isa lamang simpleng deklaratibong wika,
na may mahusay na tinukoy na daloy ng kontrol, at pamilyar na semantika. Mayroon itong mga variable na kumikilos
karaniwang ang paraan na iyong inaasahan sa kanila, mga subroutine, daloy ng kontrol, at iba pa. doon
ay walang espesyal na syntax na ipinakilala para sa Cons. Ang paggamit ng Perl bilang isang scripting language
pinapasimple ang gawain ng pagpapahayag ng naaangkop na solusyon sa madalas na kumplikado
mga kinakailangan ng isang build.

Kamusta, Mundo!

Upang pagtibayin ang sumusunod na talakayan, narito kung paano mo mabubuo ang Kamusta, Mundo! C
application na may Cons:

$env = bagong cons();
Programa $env 'hello', 'hello.c';

Kung i-install mo ang script na ito sa isang direktoryo, pinangalanan ang script Tayuan, at likhain ang
kumusta.c source file sa parehong direktoryo, pagkatapos ay maaari mong i-type ang `cons hello' para buuin ang
application:

% cons hello
cc -c hello.c -o hello.o
cc -o hello hello.o

konstruksyon kapaligiran

Ang isang pangunahing pagpapasimple ng Cons ay ang ideya ng a konstruksyon kapaligiran. Isang construction
kapaligiran ay isang bagay nailalarawan sa pamamagitan ng isang set ng key/value pairs at isang set ng pamamaraan.
Upang sabihin sa Cons kung paano bumuo ng isang bagay, ginagamit mo ang naaangkop na paraan sa pamamagitan ng isang
angkop na kapaligiran sa pagtatayo. Isaalang-alang ang sumusunod na halimbawa:

$env = bagong cons(
CC => 'gcc',
LIBS => 'libworld.a'
);

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

Sa kasong ito, sa halip na gamitin ang default na kapaligiran ng konstruksiyon, tulad ng mayroon kami
na-override ang halaga ng `CC' upang ang katumbas ng GNU C Compiler ay gamitin, sa halip. Since
itong bersyon ng Kamusta, Mundo! nangangailangan ng library, libworld.a, tinukoy namin na anuman
program na naka-link sa kapaligiran na ito ay dapat na naka-link sa library na iyon. Kung ang library
umiiral na, mabuti at mabuti, ngunit kung hindi, kailangan din nating isama ang pahayag:

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

Ngayon kung nag-type ka ng `cons hello', ang library ay bubuuin bago i-link ang program, at,
siyempre, ang `gcc' ay gagamitin upang i-compile ang parehong mga module:

% cons hello
gcc -c hello.c -o hello.o
gcc -c world.c -o world.o
ar r libworld.a world.o
ar: paglikha ng libworld.a
ranlib libworld.a
gcc -o hello hello.o libworld.a

Awtomatik at matapos pagpapasustento pagsusuri

Sa Cons, ang mga dependency ay awtomatikong hinahawakan. Pagpapatuloy sa nakaraang halimbawa, tandaan
na kapag binago natin mundo.c, mundo.o ay muling pinagsama-sama, libworld.a muling nilikha, at hoy
muling na-link:

% vi mundo.c
[EDIT]
% cons hello
gcc -c world.c -o world.o
ar r libworld.a world.o
ar: paglikha ng libworld.a
ranlib libworld.a
gcc -o hello hello.o libworld.a

Ito ay medyo simpleng halimbawa: Cons ``alam'' mundo.o depende sa mundo.c, Dahil
ang dependency ay tahasang naka-set up ng `Library' na paraan. Alam din nito iyon libworld.a
depende sa mundo.o at na hoy depende sa libworld.a, lahat para sa magkatulad na dahilan.

Ngayon lumalabas na kumusta.c kasama rin ang file ng kahulugan ng interface, mundo.h:

% emacs mundo.h
[EDIT]
% cons hello
gcc -c hello.c -o hello.o
gcc -o hello hello.o libworld.a

Paano nalaman ni Cons iyon kumusta.c Kabilang mundo.h, At na hello.o dapat samakatuwid ay
muling pinagsama-sama? Sa ngayon, sapat na itong sabihin kapag isinasaalang-alang kung o hindi hello.o ay up-
hanggang sa kasalukuyan, ang Cons ay gumagamit ng scanner para sa dependency nito, kumusta.c. Ang scanner na ito ay nagsasaad ng
mga file na kasama ng kumusta.c upang makabuo ng isang listahan ng mga karagdagang dependency, lampas sa mga iyon
ginawang tahasan ng Cons script. Ang prosesong ito ay recursive: anumang mga file na kasama ni
ii-scan din ang mga kasamang file.

Hindi ba ito mahal? Ang sagot ay depende. Kung gagawin mo ang isang buong build ng isang malaking system,
ang oras ng pag-scan ay hindi gaanong mahalaga. Kung gagawin mo ang isang muling pagtatayo ng isang malaking sistema, gagawin ng Cons
gumugol ng sapat na oras sa pag-iisip tungkol dito bago ito magpasya na walang dapat gawin
tapos na (bagaman hindi kinakailangang mas maraming oras kaysa gumawa!). Ang mabuting balita ay nagagawa ito ng Cons
napakadaling intelligent na i-subset ang iyong build, kapag gumagawa ka ng mga localized na pagbabago.

Awtomatik global magtayo sequencing

Dahil ang Cons ay gumagawa ng buo at tumpak na pagsusuri ng dependency, at ginagawa ito sa buong mundo, para sa
buong build, nagagamit ng Cons ang impormasyong ito para ganap na kontrolin ang sequencing
ng build. Ang pagkakasunud-sunod na ito ay maliwanag sa mga halimbawa sa itaas, at katumbas ng kung ano
aasahan mo para sa paggawa, na ibinigay ng isang buong hanay ng mga dependencies. Sa Cons, ito ay umaabot
trivially sa mas malaki, multi-directory build. Bilang isang resulta, ang lahat ng kumplikadong kasangkot
sa pagtiyak na ang isang build ay naayos nang tama--kabilang ang multi-pass hierarchical
build--ay inalis. Tatalakayin pa natin ito sa susunod na mga seksyon.

gusali malaki mga puno--pa rin m as simple

A hierarchy of magtayo script

Ang isang mas malaking build, sa Cons, ay isinaayos sa pamamagitan ng paglikha ng isang hierarchy ng magtayo script. Sa taas
ng puno ay isang script na tinatawag Tayuan. Ang natitirang mga script, ayon sa convention, ay bawat isa
tinatawag konskript. Ang mga script na ito ay pinagsama-sama, napakasimple, ng `Build',
Mga utos na `I-export', at `Import'.

Ang Magtayo utos

Ang utos na `Build' ay kumukuha ng isang listahan ng konskript mga pangalan ng file, at inaayos ang mga ito
kasama sa build. Halimbawa:

Bumuo ng qw(
mga driver/display/Conscript
mga driver/mouse/Conscript
parser/Conscript
mga utility/Conscript
);

Ito ay isang simpleng dalawang antas na hierarchy ng build script: lahat ng subsidiary konskript file
ay binanggit sa pinakamataas na antas Tayuan file. Pansinin na hindi lahat ng mga direktoryo sa puno
kinakailangang magkaroon ng mga build script na nauugnay sa kanila.

Maaari rin itong isulat bilang isang multi-level na script. Halimbawa, ang Tayuan maaaring mag-file
naglalaman ng utos na ito:

Bumuo ng qw(
parser/Conscript
mga driver/Conscript
mga utility/Conscript
);

at ang konskript file sa driver ang direktoryo ay maaaring naglalaman nito:

Bumuo ng qw(
display/Conscript
mouse/Conscript
);

Ipinakita ng karanasan na ang dating modelo ay medyo mas madaling maunawaan, dahil ang
buong construction tree ay inilatag sa harap mo, sa pinakamataas na antas. Ang mga hybrid na scheme ay
pwede rin. Isang hiwalay na pinapanatili na bahagi na kailangang isama sa a
build tree, halimbawa, ay maaaring kumabit sa build tree sa isang lugar, ngunit tukuyin ang sarili nito
hierarchy ng konstruksiyon.

Bilang default, hindi binabago ng Cons ang gumaganang direktoryo nito sa direktoryong naglalaman ng a
sangay konskript file na kasama nito. Maaaring paganahin ang gawi na ito para sa isang build ni
pagtukoy, sa pinakamataas na antas Tayuan file:

Conscript_chdir 1;

Kapag pinagana, ang Cons ay lilipat sa subsidiary konskript file na naglalaman ng direktoryo
habang nagbabasa sa file na iyon, at pagkatapos ay bumalik sa top-level na direktoryo kapag ang file
ay na proseso na.

Inaasahan na ang gawi na ito ay magiging default sa ilang hinaharap na bersyon ng Cons.
Para maghanda para sa paglipat na ito, ang mga build na umaasa na ang Cons ay mananatili sa tuktok ng build
habang nagbabasa ito sa isang subsidiary konskript file ay dapat na tahasang hindi paganahin ang tampok na ito bilang
sumusunod:

Conscript_chdir 0;

Kamag-anak, pinakamataas na kamag-anak, at hindi mapag-aalinlanganan file pangalan

Maaaring napansin mo na ang mga pangalan ng file na tinukoy sa utos ng Build ay nauugnay sa
ang lokasyon ng script kung saan ito ginamit. Ito ay karaniwang totoo para sa ibang filename
argumento sa iba pang mga utos, masyadong, kahit na maaari rin naming banggitin dito na kung magsisimula ka
isang pangalan ng file na may hash mark, ``#'', pagkatapos ay ang file na iyon ay binibigyang-kahulugan na nauugnay sa itaas-
antas na direktoryo (kung saan ang Tayuan naninirahan ang file). At, hindi nakakagulat, kung sisimulan mo ito
na may ``/'', kung gayon ito ay itinuturing na ganap na pathname. Ito ay totoo kahit na sa mga sistema
na gumagamit ng back slash sa halip na forward slash para pangalanan ang absolute path.

paggamit module in magtayo script

Maaari mong hilahin ang mga module sa bawat isa konskript file gamit ang normal na Perl `use' o `require'
mga pahayag:

Gumamit ng Ingles;
nangangailangan ng My::Module;

Ang bawat `use' o `require' ay nakakaapekto lamang sa isa konskript file kung saan ito lilitaw. Upang gumamit ng a
module sa maramihang konskript file, dapat kang maglagay ng `use' o `require' statement sa bawat isa
isa na nangangailangan ng modyul.

saklaw of mga variable

Ang pinakamataas na antas Tayuan file at lahat konskript Ang mga file ay nagsisimula sa buhay sa isang karaniwan, hiwalay na Perl
Pakete. Kahinaan kinokontrol ang talahanayan ng simbolo para sa pakete upang, ang talahanayan ng simbolo para sa
bawat script ay walang laman, maliban sa Tayuan file, na nakakakuha ng ilan sa command line
mga argumento. Ang lahat ng mga variable na itinakda o ginagamit, samakatuwid, ay itinakda ng script
mismo--hindi sa pamamagitan ng ilang panlabas na script.

Ang mga variable ay maaaring tahasang angkat sa pamamagitan ng isang script mula sa parent script nito. Upang mag-import ng a
variable, ito ay dapat na nai-export ng magulang at nasimulan (kung hindi man ay isang error
magaganap).

Ang I-export utos

Ang utos na `I-export' ay ginagamit tulad ng sa sumusunod na halimbawa:

$env = bagong cons();
$INCLUDE = "#export/include";
$LIB = "#export/lib";
I-export ang qw( env INCLUDE LIB );
Bumuo ng qw( util/Conscript );

Ang mga halaga ng mga simpleng variable na binanggit sa listahan ng `I-export' ay aalisin
sa pamamagitan ng anumang kasunod na utos ng `Build'. Ang utos na `I-export' ay mag-e-export lamang ng Perl skalar
mga variable, iyon ay, mga variable na ang pangalan ay nagsisimula sa `$'. Iba pang mga variable, bagay, atbp.
maaaring i-export sa pamamagitan ng sanggunian--ngunit ang lahat ng mga script ay magre-refer sa parehong bagay, at ito
bagay ay dapat ituring na read-only ng mga subsidiary na script at ng orihinal
pag-export ng script. Gayunpaman, katanggap-tanggap na magtalaga ng bagong halaga sa na-export na scalar
variable--na hindi magbabago sa pinagbabatayan na variable na isinangguni. Ang pagkakasunod-sunod na ito, para sa
halimbawa, ay OK:

$env = bagong cons();
I-export ang qw( env INCLUDE LIB );
Bumuo ng qw( util/Conscript );
$env = new cons(CFLAGS => '-O');
Bumuo ng qw( other/Conscript );

Hindi mahalaga kung nakatakda ang variable bago o pagkatapos ng utos na `I-export'. Ang
mahalagang bagay ay ang halaga ng variable sa oras na ang `Build' command ay naisakatuparan.
Ito ay kung ano ang makakakuha ng squirreled layo. Anumang kasunod na mga utos na `I-export', nga pala,
pawalang-bisa ang una: dapat mong banggitin ang lahat ng mga variable na nais mong i-export sa bawat isa
utos na `I-export'.

Ang Angkat utos

Ang mga variable na na-export ng command na `Export' ay maaaring ma-import sa mga subsidiary na script ng
`Import' na utos. Ang subsidiary na script ay palaging nag-i-import ng mga variable nang direkta mula sa
superior script. Isaalang-alang ang halimbawang ito:

Mag-import qw( env INCLUDE );

Ito ay ligal lamang kung ang parent script ay parehong nag-export ng `$env' at `$INCLUDE'. Dapat din
ay nagbigay ng bawat isa sa mga variable na ito ng mga halaga. OK lang na ang subsidiary script lang
mag-import ng subset ng mga na-export na variable (sa halimbawang ito, `$LIB', na na-export ng
ang nakaraang halimbawa, ay hindi na-import).

Ang lahat ng na-import na variable ay awtomatikong muling nai-export, kaya ang pagkakasunud-sunod ay:

Mag-import ng qw ( env INCLUDE );
Bumuo ng qw ( beneath-me/Conscript );

ay magbibigay ng parehong `$env' at `$INCLUDE' sa subsidiary na file. Kung `$env' lang ang mangyayari
na-export, kung gayon ang mga sumusunod ay sapat na:

Mag-import ng qw ( env INCLUDE );
I-export ang qw ( env );
Bumuo ng qw ( beneath-me/Conscript );

Hindi na kailangang sabihin, ang mga variable ay maaaring lokal na baguhin bago i-invoke ang `Build' sa
subsidiary na script.

Magtayo script paghusga order

Ang tanging hadlang sa pag-order ng mga build script ay ang mga superior script
nasuri bago ang kanilang mababang mga script. Ang pinakamataas na antas Tayuan file, halimbawa, ay
nasuri muna, na sinusundan ng anumang mas mababang mga script. Ito lang talaga ang kailangan mong malaman
tungkol sa pagkakasunud-sunod ng pagsusuri, dahil karaniwang hindi nauugnay ang pagkakasunud-sunod. Isaalang-alang ang mga sumusunod
`Build' command:

Bumuo ng qw(
mga driver/display/Conscript
mga driver/mouse/Conscript
parser/Conscript
mga utility/Conscript
);

Pinili naming ilagay ang mga pangalan ng script sa alpabetikong pagkakasunud-sunod, dahil iyon ang pinaka
maginhawa para sa mga layunin ng pagpapanatili. Ang pagbabago ng order ay walang pagkakaiba sa
magtayo.

A modelo para pagbabahagi file

ilan simple mga convention

Sa anumang kumplikadong sistema ng software, kailangan ang isang paraan para sa pagbabahagi ng mga produkto ng build
itinatag. Iminumungkahi namin ang isang simpleng hanay ng mga kombensiyon na walang halagang ipatupad
Cons, ngunit napaka-epektibo.

Ang pangunahing panuntunan ay upang hilingin na ang lahat ay bumuo ng mga produkto na kailangang ibahagi sa pagitan
ang mga direktoryo ay ibinabahagi sa pamamagitan ng isang intermediate na direktoryo. Karaniwan naming tinatawag ito
i-export, at, sa isang C environment, nagbigay ng mga kumbensyonal na sub-directory ng direktoryo na ito,
tulad ng isama, lib, bin, Atbp

Ang mga direktoryo na ito ay tinukoy ng pinakamataas na antas Tayuan file. Isang simple Tayuan file para sa
a Kamusta, Mundo! application, na nakaayos gamit ang maramihang mga direktoryo, ay maaaring magmukhang ganito:

# Bumuo ng file para sa Hello, World!

# Kung saan ilalagay ang lahat ng aming ibinahaging produkto.
$EXPORT = '#export';

I-export ang qw( CONS INCLUDE LIB BIN );

# Mga karaniwang direktoryo para sa pagbabahagi ng mga produkto.
$INCLUDE = "$EXPORT/include";
$LIB = "$EXPORT/lib";
$BIN = "$EXPORT/bin";

# Isang karaniwang kapaligiran sa pagtatayo.
$CONS = bagong cons (
CPPPATH => $INCLUDE, # Isama ang landas para sa C Compilations
LIBPATH => $LIB, # Library path para sa pag-link ng mga program
LIBS => '-lworld', # Listahan ng mga karaniwang aklatan
);

Bumuo ng qw(
hello/Conscript
mundo/Conscript
);

Ang mundo ng direktoryo konskript ganito ang hitsura ng file:

# Conscript file para sa mundo ng direktoryo
Mag-import qw( CONS INCLUDE LIB );

# I-install ang mga produkto ng direktoryong ito
I-install ang $CONS $LIB, 'libworld.a';
I-install ang $CONS $INCLUDE, 'world.h';

# Panloob na mga produkto
Library $CONS 'libworld.a', 'world.c';

at ang hoy ng direktoryo konskript ganito ang hitsura ng file:

# Conscript file para sa directory hello
Mag-import qw( CONS BIN );

# Mga na-export na produkto
I-install ang $CONS $BIN, 'hello';

# Panloob na mga produkto
Programang $CONS 'hello', 'hello.c';

Upang maitayo ang a Kamusta, Mundo! program na may ganitong istraktura ng direktoryo, pumunta sa pinakamataas na antas
direktoryo, at mag-invoke ng `cons' na may naaangkop na mga argumento. Sa sumusunod na halimbawa, kami
sabihin sa Cons na buuin ang direktoryo i-export. Upang bumuo ng isang direktoryo, Cons recursively build lahat
kilalang mga produkto sa loob ng direktoryo na iyon (kung kailangan lang nilang buuin, siyempre). Kung alinman sa
ang mga produktong iyon ay nakasalalay sa iba pang mga produkto sa ibang mga direktoryo, pagkatapos ay itatayo ang mga iyon,
masyadong.

% cons export
I-install ang world/world.h bilang export/include/world.h
cc -Iexport/include -c hello/hello.c -o hello/hello.o
cc -I-export/isama ang -c world/world.c -o world/world.o
ar r world/libworld.a world/world.o
ar: paglikha ng mundo/libworld.a
ranlib world/libworld.a
I-install ang world/libworld.a bilang export/lib/libworld.a
cc -o hello/hello hello/hello.o -Lexport/lib -lworld
I-install ang hello/hello bilang export/bin/hello

Malinis, naiintindihan, independyente sa lokasyon script

Mapapansin mo na ang dalawa konskript ang mga file ay napakalinis at to-the-point. Sila lang
tukuyin ang mga produkto ng direktoryo at kung paano buuin ang mga produktong iyon. Ang mga tagubilin sa pagbuo
ay minimal: tinutukoy nila kung aling kapaligiran ng konstruksiyon ang gagamitin, ang pangalan ng produkto,
at ang pangalan ng mga input. Tandaan din na ang mga script ay lokasyon-independent: kung ikaw
nais mong muling ayusin ang iyong pinagmulang puno, malaya kang gawin ito: kailangan mo lamang baguhin ang
Tayuan file (sa halimbawang ito), upang tukuyin ang mga bagong lokasyon ng konskript mga file. Ang
ang paggamit ng isang export tree ay ginagawang madali ang layuning ito.

Tandaan din kung paano pinangangalagaan ng Cons ang maliliit na detalye para sa iyo. Lahat ng i-export mga direktoryo, para sa
halimbawa, ay awtomatikong ginawa. At ang mga naka-install na file ay talagang naka-link sa
kani-kanilang mga direktoryo ng pag-export, upang makatipid ng espasyo at oras. Ang pansin sa detalyeng ito ay nakakatipid
malaking trabaho, at ginagawang mas madali ang paggawa ng mga simple at mapapanatiling script.

Paghiwalay pinagmulan at magtayo mga puno

Madalas na kanais-nais na panatilihing ganap na hiwalay ang anumang mga nagmula na file mula sa build mula sa
source file. Ginagawa nitong mas madaling subaybayan kung ano lang ang source file, at
ginagawa rin itong mas madaling hawakan variant build, lalo na kung gusto mong bumuo ng variant
upang magkasamang umiral.

Paghiwalay magtayo at pinagmulan mga direktoryo paggamit ang link utos

Nagbibigay ang Cons ng isang simpleng mekanismo na humahawak sa lahat ng mga kinakailangang ito. Ang `Link'
Ang utos ay hinihingi tulad ng sa halimbawang ito:

Link 'build' => 'src';

Ang mga tinukoy na direktoryo ay ``naka-link'' sa tinukoy na direktoryo ng pinagmulan. Ipagpalagay na natin
na nag-set up ka ng source directory, SRC, kasama ang mga sub-directory mundo at hoy sa ibaba nito,
tulad ng sa nakaraang halimbawa. Maaari mong palitan ang orihinal na mga linya ng build na
sumusunod:

Bumuo ng qw(
build/world/Conscript
build/hello/Conscript
);

Pansinin na tinatrato mo ang konskript file na parang umiral ito sa direktoryo ng build. Ngayon kung
i-type mo ang parehong utos tulad ng dati, makakakuha ka ng mga sumusunod na resulta:

% cons export
I-install ang build/world/world.h bilang export/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 r build/world/libworld.a build/world/world.o
ar: paglikha ng build/world/libworld.a
ranlib build/world/libworld.a
I-install ang build/world/libworld.a bilang export/lib/libworld.a
cc -o build/hello/hello build/hello/hello.o -Lexport/lib -lworld
I-install ang build/hello/hello bilang export/bin/hello

Muli, inalagaan ng Cons ang mga detalye para sa iyo. Sa partikular, mapapansin mo na ang lahat
ang mga build ay ginagawa gamit ang mga source file at object file mula sa build directory. Para sa
Halimbawa, build/world/world.o ay pinagsama-sama mula sa build/world/world.c, at
export/include/world.h ay naka-install mula sa build/world/world.h. Ito ay nagagawa sa karamihan
system sa pamamagitan ng simpleng paggamit ng ``mahirap'' pag-uugnay ng mga kinakailangang file mula sa bawat pinagmulan
direktoryo sa naaangkop na direktoryo ng build.

Ang mga link ay pinananatili ng tama ng Cons, anuman ang gawin mo sa source na direktoryo.
Kung babaguhin mo ang isang source file, maaaring gawin ito ng iyong editor na ``sa lugar'' o maaari nitong palitan ang pangalan nito
una at gumawa ng bagong file. Sa huling kaso, mawawala ang anumang hard link. Cons will
tuklasin ang kundisyong ito sa susunod na oras na kailanganin ang source file, at muling iuugnay ito
angkop.

Mapapansin mo rin pala hindi kinakailangan ang mga pagbabago sa pinagbabatayan konskript
mga file. At maaari tayong magpatuloy, tulad ng makikita natin sa susunod na seksyon.

baryante gagawa

Kamusta, Mundo! para baNaNa at peAcH Mga OS

Ang mga variant build ay nangangailangan lamang ng isa pang simpleng extension. Kunin natin bilang halimbawa a
kinakailangan upang payagan ang mga build para sa parehong baNaNa at peAcH operating system. Sa kasong ito,
gumagamit kami ng distributed file system, gaya ng NFS para ma-access ang partikular na system, at
isa lamang o ang isa pa sa mga sistema ang kailangang i-compile para sa anumang ibinigay na panawagan ng
`cons'. Narito ang isang paraan na maaari naming i-set up ang Tayuan file para sa aming Kamusta, Mundo!
application:

# Bumuo ng file para sa Hello, World!

die qq(dapat tukuyin ang OS) maliban kung $OS = $ARG{OS};
die qq(Ang OS ay dapat na "peach" o "banana")
kung ang $OS ay hindi "peach" && $OS ay hindi "saging";

# Kung saan ilalagay ang lahat ng aming ibinahaging produkto.
$EXPORT = "#export/$OS";

I-export ang qw( CONS INCLUDE LIB BIN );

# Mga karaniwang direktoryo para sa pagbabahagi ng mga produkto.
$INCLUDE = "$EXPORT/include";
$LIB = "$EXPORT/lib";
$BIN = "$EXPORT/bin";

# Isang karaniwang kapaligiran sa pagtatayo.
$CONS = bagong cons (
CPPPATH => $INCLUDE, # Isama ang landas para sa C Compilations
LIBPATH => $LIB, # Library path para sa pag-link ng mga program
LIBS => '-lworld', # Listahan ng mga karaniwang aklatan
);

Ang # $BUILD ay kung saan natin kukunin ang lahat.
$BUILD = "#build/$OS";

# Sabihin ang mga kahinaan kung nasaan ang mga source file para sa $BUILD.
Link $BUILD => 'src';

Build (
"$BUILD/hello/Conscript",
"$BUILD/world/Conscript",
);

Ngayon kung mag-log in tayo sa isang peAcH system, maaari nating buuin ang ating Kamusta, Mundo! aplikasyon para diyan
platform:

% cons export OS=peach
I-install ang build/peach/world/world.h bilang export/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 r build/peach/world/libworld.a build/peach/world/world.o
ar: paglikha ng build/peach/world/libworld.a
ranlib build/peach/world/libworld.a
I-install ang build/peach/world/libworld.a bilang export/peach/lib/libworld.a
cc -o build/peach/hello/hello build/peach/hello/hello.o -Lexport/peach/lib -lworld
I-install ang build/peach/hello/hello bilang export/peach/bin/hello

Pagkakaiba-iba on a tema

Ang iba pang mga pagkakaiba-iba ng modelong ito ay posible. Halimbawa, maaari kang magpasya na gusto mo
para paghiwalayin ang iyong mga file na kasama sa platform dependent at platform independent file.
Sa kasong ito, kailangan mong tumukoy ng alternatibo sa `$INCLUDE' para sa platform-dependent
mga file. Karamihan konskript file, na bumubuo ng puro platform-independent kasama ang mga file, ay
hindi kailangang baguhin.

Baka gusto mo ring ma-compile ang iyong buong system gamit ang pag-debug o pag-profile,
halimbawa, pinagana. Magagawa mo ito sa naaangkop na mga opsyon sa command line, gaya ng
`DEBUG=on'. Ito ay isasalin sa naaangkop na platform-specific
mga kinakailangan upang paganahin ang pag-debug (maaaring kabilang dito ang pag-off sa pag-optimize, para sa
halimbawa). Maaari mong opsyonal na baguhin ang puwang ng pangalan para sa iba't ibang uri ng mga system na ito,
ngunit, gaya ng makikita natin sa susunod na seksyon, hindi mahalaga upang gawin ito, dahil maganda ang Cons
matalino tungkol sa muling pagtatayo ng mga bagay kapag binago mo ang mga opsyon.

Mga lagda

MD5 cryptographic lagda

Sa tuwing gumagawa ang Cons ng isang nagmula na file, nag-iimbak ito ng a lagda para sa file na iyon. Ang pirma
ay naka-imbak sa isang hiwalay na file, isa sa bawat direktoryo. Matapos ma-compile ang nakaraang halimbawa,
ang .magpadala file sa build/peach/world ganito ang hitsura ng direktoryo:

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

Ang unang numero ay isang timestamp--para sa isang UNIX system, ito ay karaniwang bilang ng
segundo mula noong Enero 1, 1970. Ang pangalawang halaga ay isang MD5 checksum. Ang mensahe Digest
Algorithm ay isang algorithm na, na binibigyan ng input string, ay nag-compute ng isang malakas na cryptographic
lagda para sa string na iyon. Ang MD5 checksum na nakaimbak sa .magpadala file ay, sa epekto, a
digest ng lahat ng impormasyon ng dependency para sa tinukoy na file. Kaya, halimbawa, para sa
mundo.o file, kabilang dito ang hindi bababa sa mundo.c file, at gayundin ang anumang mga file ng header na Cons
alam tungkol diyan ay kasama, direkta o hindi direkta ni mundo.c. Hindi lamang iyon, kundi ang
aktwal na command line na ginamit upang makabuo mundo.o ay din fed sa computation ng
ang pirma. Katulad nito, libworld.a nakakakuha ng pirma na ``kabilang'' lahat ng
mga lagda ng mga nasasakupan nito (at samakatuwid, transitively, ang mga lagda ng Russia at ilang bansa sa Asya.
constituents), pati na rin ang command line na lumikha ng file.

Ang pirma ng isang hindi nagmula na file ay kinokwenta, bilang default, sa pamamagitan ng pagkuha ng kasalukuyang
oras ng pagbabago ng file at ang entry name ng file (maliban kung may mangyari na a
kasalukuyan .magpadala entry para sa file na iyon, kung saan ang pirma ay ginamit).

Pansinin na hindi na kailangan para sa isang nagmula na file na umaasa sa anumang partikular Tayuan or
konskript file--kung ang mga pagbabago sa mga file na ito ay makakaapekto sa file na pinag-uusapan, kung gayon ito ang magiging
awtomatikong makikita sa lagda nito, dahil ang mga nauugnay na bahagi ng command line ay
kasama sa pirma. Walang epekto ang mga hindi nauugnay na pagbabago.

Kapag isinasaalang-alang ng Cons kung kukuha ng isang partikular na file, kung gayon, kino-compute muna nito ang
inaasahang pirma ng file. Pagkatapos ay ikinukumpara nito ang huling oras ng pagbabago ng file sa
ang oras na naitala sa .magpadala entry, kung mayroon. Kung magkatugma ang mga oras na ito, kung gayon ang
lagda na nakaimbak sa .magpadala ang file ay itinuturing na tumpak. Kung ang file ay nauna
hindi tumutugma ang lagda sa bago, inaasahang lagda, kung gayon ang file ay dapat na muling makuha.

Pansinin na ang isang file ay muling makukuha sa tuwing ang anumang bagay tungkol sa isang umaasa na file ay nagbabago. Sa
partikular, pansinin iyon anumang pagbabago sa oras ng pagbabago ng isang umaasa (pasulong o
pabalik sa oras) ay pipilitin ang muling pagsasama-sama ng nagmula na file.

Ang paggamit ng mga lagdang ito ay isang napakasimple, mahusay, at epektibong paraan ng
pagpapabuti--kapansin-pansing--ang reproducibility ng isang system.

Ipapakita namin ito sa isang simpleng halimbawa:

# Simple "Hello, World!" Bumuo ng file
$CFLAGS = '-g' kung $ARG{DEBUG} eq 'on';
$CONS = bagong cons(CFLAGS => $CFLAGS);
Programang $CONS 'hello', 'hello.c';

Pansinin kung paano muling nagko-compile ang Cons sa mga naaangkop na oras:

% cons hello
cc -c hello.c -o hello.o
cc -o hello hello.o
% cons hello
cons: "hello" ay up-to-date.
% cons DEBUG=sa hello
cc -g -c hello.c -o hello.o
cc -o hello hello.o
% cons DEBUG=sa hello
cons: "hello" ay up-to-date.
% cons hello
cc -c hello.c -o hello.o
cc -o hello hello.o

kodigo Mga Repository

Maraming mga organisasyon ng software development ang magkakaroon ng isa o higit pang direktoryo ng central repository
mga puno na naglalaman ng kasalukuyang source code para sa isa o higit pang mga proyekto, pati na rin ang hinango
object file, library, at executable. Upang mabawasan ang hindi kinakailangang recompilation,
ito ay kapaki-pakinabang na gumamit ng mga file mula sa repository upang bumuo ng development software--ipagpalagay, ng
siyempre, na walang mas bagong dependency file na umiiral sa lokal na build tree.

Repository

Nagbibigay ang Cons ng mekanismo upang tukuyin ang isang listahan ng mga imbakan ng code na hahanapin,
in-order, para sa mga source file at derived na file na hindi nakita sa local build directory tree.

Ang mga sumusunod na linya sa a Tayuan Ang file ay magtuturo sa Cons na tumingin muna sa ilalim ng
/usr/experiment/repository direktoryo at pagkatapos ay sa ilalim ng /usr/product/repository direktoryo:

Imbakan qw (
/usr/experiment/repository
/usr/product/repository
);

Ang mga direktoryo ng repositoryo na tinukoy ay maaaring maglaman ng mga source file, nagmula na mga file (mga bagay,
mga aklatan at mga executable), o pareho. Kung walang lokal na file (pinagmulan o hinango) sa ilalim
ang direktoryo kung saan ang Cons ay pinaandar, pagkatapos ay natagpuan ang unang kopya ng isang parehong pinangalanang file
sa ilalim ng isang direktoryo ng imbakan ay gagamitin upang bumuo ng anumang mga lokal na nagmula na mga file.

Ang Cons ay nagpapanatili ng isang pandaigdigang listahan ng mga direktoryo ng mga repositoryo. Ang mga kahinaan ay aalisin ang
kasalukuyang direktoryo, at anumang hindi umiiral na mga direktoryo, mula sa listahan.

Pagkatuklas ang Tayuan file in a Repository

Maghahanap din ang Cons Tayuan at konskript mga file sa repository tree o mga puno.
Ito ay humahantong sa isang sitwasyon ng manok-at-itlog, bagaman: ano ang hitsura mo sa isang puno ng repositoryo
para sa isang Tayuan file kung ang Tayuan Sinasabi sa iyo ng file kung saan ang repositoryo? Para makuha
sa paligid nito, maaaring tukuyin ang mga repositoryo sa pamamagitan ng mga opsyon sa `-R' sa command line:

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

Anumang mga direktoryo ng imbakan na tinukoy sa Tayuan or konskript idaragdag ang mga file
sa mga direktoryo ng repositoryo na tinukoy ng command-line na `-R' na mga opsyon.

Repository pinagmulan file

Kung ang source code (isama ang konskript file) para sa bersyon ng library ng Kamusta,
Mundo! Ang C application ay nasa isang repositoryo (na walang nagmula na mga file), gagamitin ng Cons ang
repository source file upang lumikha ng mga lokal na object file at executable file:

% 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 world.o
ar r libworld.a world.o
ar: paglikha ng libworld.a
ranlib libworld.a
gcc -o hello hello.o libworld.a

Ang paggawa ng isang lokal na source file ay magiging sanhi ng Cons na muling buuin ang naaangkop na nagmula na file o
file:

% pico mundo.c
[EDIT]
% cons -R /usr/src_only/repository hello
gcc -c world.c -o world.o
ar r libworld.a world.o
ar: paglikha ng libworld.a
ranlib libworld.a
gcc -o hello hello.o libworld.a

At ang pag-alis ng lokal na source file ay magiging sanhi ng Cons na bumalik sa pagbuo ng hinango
mga file mula sa mapagkukunan ng imbakan:

% rm mundo.c
% cons -R /usr/src_only/repository hello
gcc -c /usr/src_only/repository/world.c -o world.o
ar r libworld.a world.o
ar: paglikha ng libworld.a
ranlib libworld.a
gcc -o hello hello.o libworld.a

Repository nanggaling file

Kung ang isang repository tree ay naglalaman ng mga nagmula na file (karaniwang object file, library, o
executable), Gagawin ng Cons ang normal nitong pagkalkula ng lagda upang magpasya kung ang
ang repository file ay napapanahon o ang isang nagmula na file ay dapat na lokal na binuo. Ibig sabihin,
upang matiyak ang tamang pagkalkula ng lagda, ang isang puno ng repositoryo ay dapat ding naglalaman ng
.magpadala mga file na nilikha ng Cons kapag bumubuo ng mga nagmula na file.

Ito ay karaniwang magagawa sa pamamagitan ng pagbuo ng software sa repositoryo (o,
Bilang kahalili, sa isang direktoryo ng build, at pagkatapos ay kopyahin ang resulta sa repositoryo):

% cd /usr/all/repository
% cons hello
gcc -c hello.c -o hello.o
gcc -c world.c -o world.o
ar r libworld.a world.o
ar: paglikha ng libworld.a
ranlib libworld.a
gcc -o hello hello.o libworld.a

(Ito ay ligtas kahit na ang Tayuan Ang file ay naglilista ng /usr/all/repository direktoryo sa a
Utos ng `Repository' dahil aalisin ng Cons ang kasalukuyang direktoryo mula sa repositoryo
listahan.)

Ngayon kung gusto naming bumuo ng kopya ng application gamit ang sarili namin kumusta.c file, kailangan lang namin
upang lumikha ng isang kinakailangang source file, at gamitin ang `-R' na opsyon upang gamitin ng Cons ang iba
mga file mula sa imbakan:

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

Pansinin na ang Cons ay hindi nag-abala na muling likhain ang isang lokal libworld.a library (o muling i-compile ang
mundo.o module), ngunit sa halip ay gumagamit ng na-compiled na bersyon mula sa repositoryo.

Dahil ang mga pirma ng MD5 na inilalagay ni Cons sa .magpadala Ang file ay naglalaman ng mga timestamp para sa
nagmula sa mga file, ang mga timestamp ng lagda ay dapat tumugma sa mga timestamp ng file para sa isang lagda
maituturing na wasto.

Maaaring baguhin ng ilang software system ang mga timestamp sa mga repository file (sa pamamagitan ng pagkopya sa kanila,
hal), kung saan ang Cons ay, bilang default, ay ipagpalagay na ang mga lagda sa repositoryo ay hindi wasto
at muling buuin ang mga file nang hindi kinakailangan. Maaaring mabago ang pag-uugaling ito sa pamamagitan ng pagtukoy:

Repository_Sig_Times_OK 0;

Sinasabi nito sa Cons na huwag pansinin ang mga timestamp kapag nagpapasya kung wasto ang isang lagda. (Tandaan
na ang pag-iwas sa sanity check na ito ay nangangahulugan na dapat mayroong tamang kontrol sa repositoryo
tree upang matiyak na ang mga nagmula na file ay hindi mababago nang hindi ina-update ang .magpadala
lagda.)

Lokal kopya of file

Kung ang repository tree ay naglalaman ng kumpletong resulta ng isang build, at sinusubukan naming bumuo mula sa
ang repository na walang anumang mga file sa aming lokal na puno, isang bagay na medyo nakakagulat
nangyayari:

% mkdir $HOME/build2
% cd $HOME/build2
% cons -R /usr/all/repository hello
cons: "hello" ay up-to-date.

Bakit sinasabi ni Cons na ang hoy up-to-date ang programa kapag walang hoy programa sa
ang lokal na direktoryo ng build? Dahil ang repositoryo (hindi ang lokal na direktoryo) ay naglalaman ng
sunod sa panahon hoy program, at ang Cons ay wastong tinutukoy na walang kailangang gawin
muling buuin itong up-to-date na kopya ng file.

Mayroong, gayunpaman, maraming beses kung saan angkop na tiyakin na ang isang lokal na kopya ng a
palaging umiiral ang file. Ang isang packaging o pagsubok na script, halimbawa, ay maaaring ipalagay na tiyak
ang mga nabuong file ay umiiral nang lokal. Sa halip na ipaalam sa mga subsidiary na script na ito ang
direktoryo ng imbakan, ang utos na `Lokal' ay maaaring idagdag sa a Tayuan or konskript maghain sa
tukuyin na ang isang partikular na file o mga file ay dapat lumitaw sa lokal na direktoryo ng build:

lokal qw(
hoy
);

Pagkatapos, kung muling patakbuhin namin ang parehong command, gagawa ang Cons ng lokal na kopya ng program mula sa
kopya ng repositoryo (sinasabi sa iyo na ginagawa nito):

% cons -R /usr/all/repository hello
Lokal na kopya ng hello mula sa /usr/all/repository/hello
cons: "hello" ay up-to-date.

Pansinin iyon, dahil ang paggawa ng lokal na kopya ay hindi itinuturing na isang "build" ng
hoy file, iniulat pa rin ng Cons na ito ay napapanahon.

Ang paglikha ng mga lokal na kopya ay pinakakapaki-pakinabang para sa mga file na ini-install sa isang
intermediate na direktoryo (para sa pagbabahagi sa ibang mga direktoryo) sa pamamagitan ng utos na `Install'.
Ang kasama ng utos na `Install' para sa isang file na may kasamang utos na `Local' ay kaya
karaniwan na ang Cons ay nagbibigay ng utos na `Install_Local' bilang isang maginhawang paraan upang gawin pareho:

Install_Local $env, '#export', 'hello';

ay eksaktong katumbas ng:

I-install ang $env '#export', 'hello';
Lokal na '#export/hello';

Parehong ang mga utos na `Local' at `Install_Local' ay nag-a-update sa lokal .magpadala file gamit ang
naaangkop na mga lagda ng file, upang ang mga pagbuo sa hinaharap ay maisagawa nang tama.

Repository pagpapasustento pagsusuri

Dahil sa built-in na pag-scan nito, hahanapin ng Cons ang mga tinukoy na repository tree para sa kasama
.h mga file. Maliban kung alam din ng compiler ang tungkol sa mga puno ng repositoryo, gayunpaman, ito ay magiging
hindi mahanap .h mga file na umiiral lamang sa isang repositoryo. Kung, halimbawa, ang kumusta.c
Kasama sa file ang hello.h file sa kasalukuyang direktoryo nito:

% cons -R /usr/all/repository hello
gcc -c /usr/all/repository/hello.c -o hello.o
/usr/all/repository/hello.c:1: hello.h: Walang ganoong file o direktoryo

Ang paglutas sa problemang ito ay nagpipilit sa ilang mga kinakailangan sa paraan ng mga kapaligiran ng konstruksiyon
tinukoy at sa paraan kung paano ginagamit ang C `#include' preprocessor directive para isama ang mga file.

Upang ipaalam sa compiler ang tungkol sa mga repository tree, ang Cons ay magdaragdag ng naaangkop na `-I'
mga flag sa compilation command. Nangangahulugan ito na ang variable na `CPPPATH' sa
construct environment ay dapat na tahasang tukuyin ang lahat ng mga subdirectory na hahanapin
para sa mga kasamang file, kasama ang kasalukuyang direktoryo. Dahil dito, maaari nating ayusin ang nasa itaas
halimbawa sa pamamagitan ng pagbabago sa paglikha ng kapaligiran sa Tayuan mag-file tulad ng sumusunod:

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

Dahil sa depinisyon ng variable na `CPPPATH', magbubunga ito, kapag muli nating isinagawa ang
utos:

% 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

Ang pagkakasunud-sunod ng mga flag na `-I' ay umuulit, para sa C preprocessor, ang parehong repository-
path ng paghahanap ng direktoryo na ginagamit ng Cons para sa sarili nitong pagsusuri sa dependency. Kung meron
maramihang mga repositoryo at maramihang mga direktoryo ng `CPPPATH', idaragdag ng Cons ang repositoryo
mga direktoryo sa simula ng bawat direktoryo ng `CPPPATH', na mabilis na nagpaparami ng numero
ng mga watawat ng `-I'. Bilang isang matinding halimbawa, a Tayuan file na naglalaman ng:

Imbakan qw(
/u1
/u2
);

$env = bagong cons(
CPPPATH => 'a:b:c',
);

Magbibigay ng compilation command ng:

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 hello.o

Dahil umaasa ang Cons sa mga flag na `-I' ng compiler upang ipaalam ang pagkakasunud-sunod kung saan
Dapat hanapin ang mga direktoryo ng imbakan, ang pangangasiwa ng Cons sa mga direktoryo ng imbakan ay
sa panimula ay hindi tugma sa paggamit ng mga double-quote sa mga direktiba ng `#include' sa iyong C
source code:

#include "file.h" /* HUWAG GAMITIN ANG DOUBLE-QUOTES NA KATULAD ITO */

Ito ay dahil karamihan sa mga C preprocessor, kapag nahaharap sa ganoong direktiba, ay palaging mauuna
hanapin ang direktoryo na naglalaman ng source file. Pinapahina nito ang detalyadong `-ako'
mga opsyon na ginagawa ng Cons upang gawin ang preprocessor na umayon sa gusto nitong paghahanap
landas.

Dahil dito, kapag gumagamit ng mga repository tree sa Cons, palagi gumamit ng mga anggulo-bracket para sa kasama
file:

#isama /* GAMITIN ANG ANGLE-BRACKET SA HALIP */

Repository_List

Nagbibigay ang Cons ng utos na `Repository_List' upang ibalik ang isang listahan ng lahat ng mga direktoryo ng repositoryo
sa kanilang kasalukuyang order sa paghahanap. Magagamit ito para sa pag-debug, o para gumawa ng mas kumplikadong Perl
bagay:

@list = Repository_List;
print join(' ', @list), "\n";

Repository pakipagtulungan sa iba Kahinaan mga tampok

Ang paghawak ng Cons sa mga puno ng repository ay nakikipag-ugnayan nang tama sa iba pang mga tampok ng Cons--na
para sabihin, karaniwang ginagawa nito ang iyong inaasahan.

Kapansin-pansin, ang mga puno ng repository ay nakikipag-ugnayan nang tama, at sa halip ay malakas, sa 'Link'
utos. Ang isang repository tree ay maaaring maglaman ng isa o higit pang mga subdirectory para sa mga build ng bersyon
itinatag sa pamamagitan ng `Link' sa isang source subdirectory. Hahanapin ng Cons ang mga nagmula na file sa
ang naaangkop na build subdirectory sa ilalim ng repository tree.

default target

Hanggang ngayon, ipinakita namin ang paggamit ng Cons na may tahasang target na buuin:

% cons hello

Karaniwan, ang Cons ay hindi gumagawa ng anuman maliban kung ang isang target ay tinukoy, ngunit tumutukoy sa '.'
(ang kasalukuyang direktoryo) ay bubuo ng lahat:

% cons # ay hindi bumubuo ng anuman

% cons . Binubuo ng # ang lahat sa ilalim ng top-level na direktoryo

Pagdaragdag ng `Default' na paraan sa anuman Tayuan or konskript file ay idagdag ang tinukoy
mga target sa isang listahan ng mga default na target. Ang mga kahinaan ay bubuo ng mga default na ito kung wala
mga target na tinukoy sa command line. Kaya ang pagdaragdag ng sumusunod na linya sa pinakamataas na antas
Tayuan Ang file ay gayahin ang karaniwang pag-uugali ni Make sa pagbuo ng lahat bilang default:

Default na '.';

Ang mga sumusunod ay magdaragdag ng hoy at paalam mga utos (sa parehong direktoryo ng
Tayuan or konskript file) sa default na listahan:

Default qw(
hoy
paalam
);

Ang `Default' na paraan ay maaaring gamitin nang higit sa isang beses upang magdagdag ng mga target sa default na listahan.

Pumipili gagawa

Nagbibigay ang Cons ng dalawang paraan para sa pagbawas ng laki ng ibinigay na build. Ang una ay sa pamamagitan ng pagtukoy
mga target sa command line, at ang pangalawa ay isang paraan para sa pruning ng build tree. gagawin namin
isaalang-alang muna ang target na detalye.

Pumipili pag-target

Tulad ng make, pinapayagan ng Cons ang detalye ng ``target'' sa command line. Cons target
maaaring alinman sa mga file o mga direktoryo. Kapag ang isang direktoryo ay tinukoy, ito ay isang maikling-
hand notation para sa bawat derivable na produkto--na alam ng Cons--sa tinukoy
direktoryo at sa ibaba. Halimbawa:

% cons build/hello/hello.o

ibig sabihin ay bumuo hello.o at lahat ng iyon hello.o maaaring kailanganin. Ito ay mula sa isang nakaraan
bersyon ng Kamusta, Mundo! programa kung saan hello.o nakasalalay sa
export/include/world.h. Kung hindi up-to-date ang file na iyon (dahil may nag-modify
src/world/world.h), pagkatapos ito ay muling itatayo, kahit na ito ay nasa isang direktoryo na malayo mula sa
bumuo/hello.

Sa halimbawang ito:

% cons build

Lahat ng nasa magtayo ang direktoryo ay binuo, kung kinakailangan. Muli, maaari itong magdulot ng mas maraming file
itatayo. Sa partikular, pareho export/include/world.h at export/lib/libworld.a ay
hinihiling ng bumuo/hello direktoryo, at sa gayon ay itatayo ang mga ito kung luma na ang mga ito.

Kung gagawin natin, sa halip:

% cons export

pagkatapos lamang ang mga file na dapat na mai-install sa direktoryo ng pag-export ay muling itatayo, kung
kinakailangan, at pagkatapos ay i-install doon. Tandaan na ang `cons build' ay maaaring bumuo ng mga file na `cons
export' ay hindi bumubuo, at kabaliktaran.

Hindi ``espesyal'' target

Sa Cons, hindi kailangan ang make-style na ``special'' na mga target. Ang pinakasimpleng analog na may Cons
ay gumamit ng espesyal i-export mga direktoryo, sa halip. Ipagpalagay natin, halimbawa, na mayroon kang a
buong serye ng mga unit test na nauugnay sa iyong code. Ang mga pagsubok ay nakatira sa
source na direktoryo malapit sa code. Karaniwan, gayunpaman, hindi mo gustong buuin ang mga pagsubok na ito.
Ang isang solusyon ay ibigay ang lahat ng mga tagubilin sa pagbuo para sa paggawa ng mga pagsubok, at pagkatapos ay sa
i-install ang mga pagsubok sa isang hiwalay na bahagi ng puno. Kung i-install namin ang mga pagsubok sa isang nangungunang antas
tinawag na direktoryo pagsusulit, pagkatapos:

% cons na mga pagsubok

bubuo ng lahat ng mga pagsubok.

% cons export

bubuo ng produksyon na bersyon ng system (ngunit hindi ang mga pagsubok), at:

% cons build

marahil ay dapat na iwasan (dahil ito ay mag-compile ng mga pagsubok nang hindi kinakailangan).

Kung gusto mong bumuo ng isang pagsubok lamang, maaari mong tahasang pangalanan ang pagsubok (sa
alinman sa pagsusulit direktoryo o ang magtayo direktoryo). Maaari mo ring pagsama-samahin ang mga pagsubok
sa isang maginhawang hierarchy sa loob ng direktoryo ng mga pagsubok. Hindi kailangan ng hierarchy na ito
kinakailangang tumugma sa hierarchy ng pinagmulan, sa parehong paraan tulad ng hierarchy ng pagsasama
marahil ay hindi tumutugma sa pinagmulang hierarchy (ang kasamang hierarchy ay malamang na hindi higit pa
kaysa sa dalawang antas na malalim, para sa mga programang C).

Kung nais mong bumuo ng ganap na lahat ng bagay sa puno (napapailalim sa anumang mga pagpipilian na iyong
piliin), maaari mong gamitin ang:

% cons .

Ito ay hindi partikular na mahusay, dahil ito ay kalabisan lakaran ang lahat ng mga puno,
kabilang ang puno ng pinagmulan. Ang source tree, siyempre, ay maaaring may mga buildable na bagay
ito--walang pumipigil sa iyong gawin ito, kahit na karaniwan kang bumuo sa isang hiwalay na build
tree.

Magtayo Pinuputol

Kasabay ng pagpili ng target, magtayo pruning maaaring gamitin upang bawasan ang saklaw ng
magtayo. Sa nakaraang halimbawa ng peAcH at baNaNa, nakita na natin kung paano pinaandar ng script
ang build pruning ay maaaring gamitin upang gawing available lamang ang kalahati ng potensyal na build para sa anumang naibigay
panawagan ng `cons'. Nagbibigay din ang Cons, bilang kaginhawahan, ng command line convention na
nagpapahintulot sa iyo na tukuyin kung alin konskript ang mga file ay talagang nakakakuha ng ``built''--iyon ay, incorporated
papunta sa build tree. Halimbawa:

% cons build +world

Ang argumentong `+' ay nagpapakilala ng isang regular na expression ng Perl. Ito ay dapat, siyempre, ma-quote sa
ang antas ng shell kung mayroong anumang mga shell meta-character sa loob ng expression. Ang
ang expression ay tumutugma sa bawat isa konskript file na nabanggit sa isang `Build'
statement, at ang mga script lang na may tugmang pangalan ang aktwal na isinama sa
magtayo ng puno. Pinapayagan ang maraming ganoong argumento, kung saan ang isang tugma laban sa alinman sa mga ito
ay sapat na upang maisama ang isang script.

Sa halimbawa, sa itaas, ang hoy ang programa ay hindi itatayo, dahil ang Cons ay magkakaroon ng no
kaalaman sa script hello/Conscript. ang libworld.a itatayo ang archive, gayunpaman, kung
kailangan.

Mayroong ilang mga gamit para sa build pruning sa pamamagitan ng command line. Marahil ang pinaka-kapaki-pakinabang
ay ang kakayahang gumawa ng mga lokal na pagbabago, at pagkatapos, na may sapat na kaalaman sa
kahihinatnan ng mga pagbabagong iyon, paghigpitan ang laki ng build tree upang mapabilis
ang oras ng muling pagtatayo. Ang pangalawang gamit para sa build pruning ay ang aktibong pagpigil sa muling pagsasama-sama
ng ilang partikular na file na alam mong muling iko-compile dahil sa, halimbawa, isang binagong file ng header.
Maaaring alam mo na ang alinman sa mga pagbabago sa header file ay hindi materyal, o ang
ang mga pagbabago ay maaaring ligtas na balewalain para sa karamihan ng puno, para sa mga layunin ng pagsubok. Sa Cons, ang
Ang pananaw ay praktikal na aminin ang ganitong uri ng pag-uugali, na may pag-unawa na
sa susunod na buong build lahat ng kailangang itayo muli ay magiging. Walang katumbas
sa isang utos na ``make touch'', upang markahan ang mga file bilang permanenteng napapanahon. Kaya kahit anong panganib iyon
natamo sa pamamagitan ng build pruning ay pinapagaan. Para sa pagpapalabas ng kalidad ng trabaho, malinaw naman, inirerekomenda namin
na hindi ka gumagamit ng build pruning (perpektong OK na gamitin sa panahon ng pagsasama, gayunpaman,
para sa pagsuri ng compilation, atbp. Siguraduhin lamang na gumawa ng walang limitasyong build bago gumawa
ang pagsasama).

Pansamantala overrides

Nagbibigay ang Cons ng napakasimpleng mekanismo para sa pag-override ng mga aspeto ng isang build. Ang kakanyahan ay
na sumulat ka ng override na file na naglalaman ng isa o higit pang mga command na `Override', at ikaw
tukuyin ito sa command line, kapag nagpatakbo ka ng `cons':

% cons -o sa pag-export

gagawa ng i-export direktoryo, kasama ang lahat ng nagmula na mga file na napapailalim sa mga override na naroroon
nasa sa ibabaw file. Kung iiwan mo ang opsyong `-o', lahat ng kailangan para alisin
lahat ng mga override ay muling itatayo.

Sobra kapaligiran mga variable

Ang override na file ay maaaring maglaman ng dalawang uri ng mga override. Ang una ay ang papasok na kapaligiran
mga variable. Ang mga ito ay karaniwang naa-access ng Tayuan file mula sa `%ENV' hash
variable. Maaaring ma-override ang mga ito sa override na file sa pamamagitan ng pagtatakda ng
naaangkop na mga elemento ng `%ENV' (maaari ding ma-override ang mga ito sa kapaligiran ng user,
syempre).

Ang Magpawalang-bisa utos

Ang pangalawang uri ng pag-override ay nagagawa gamit ang utos na `Override', na mukhang
ito:

I-override , => , => , ...;

Ang regular na expression regexp ay itinugma laban sa bawat nagmula na file na isang kandidato
para sa pagtatayo. Kung ang nagmula na file ay tumutugma, ang variable/value pairs ay ginagamit upang
i-override ang mga value sa construction environment na nauugnay sa nagmula na file.

Ipagpalagay natin na mayroon tayong kapaligiran sa pagtatayo tulad nito:

$CONS = bagong cons(
COPT => '',
CDBG => '-g',
CFLAGS => '%COPT %CDBG',
);

Pagkatapos kung mayroon kaming isang override na file sa ibabaw naglalaman ng utos na ito:

I-override ang '\.o$', COPT => '-O', CDBG => '';

pagkatapos ay anumang `cons' invocation na may `-o over' na lumilikha .o mga file sa pamamagitan ng kapaligirang ito ay
maging sanhi ng pagsasama-sama ng mga ito sa `-O 'at walang `-g'. Ang override ay maaaring, siyempre, ay
pinaghihigpitan sa isang direktoryo sa pamamagitan ng naaangkop na pagpili ng isang regular na expression.

Narito ang orihinal na bersyon ng Hello, World! programa, na binuo gamit ang kapaligirang ito.
Tandaan na muling itinatayo ng Cons ang mga naaangkop na piraso kapag inilapat o inalis ang override:

% cons hello
cc -g -c hello.c -o hello.o
cc -o hello hello.o
% cons -o over hello
cc -O -c hello.c -o hello.o
cc -o hello hello.o
% cons -o over hello
cons: "hello" ay up-to-date.
% cons hello
cc -g -c hello.c -o hello.o
cc -o hello hello.o

Mahalaga na ang utos na `I-override' ay gagamitin lamang para sa pansamantalang, on-the-fly
mga override na kinakailangan para sa pag-unlad dahil ang mga override ay hindi platform independent at
dahil masyado silang umaasa sa matalik na kaalaman sa mga gawa ng mga script. Para sa
pansamantalang paggamit, gayunpaman, sila mismo ang gusto mo.

Tandaan na kapaki-pakinabang pa rin na magbigay, halimbawa, ng kakayahang lumikha ng ganap na na-optimize
bersyon ng isang sistema para sa paggamit ng produksyon--mula sa Tayuan at konskript mga file. Sa ganitong paraan
maaari mong iangkop ang na-optimize na system sa platform. Kung saan kailangan ang mga trade-off ng optimizer
ginawa (ang mga partikular na file ay maaaring hindi pinagsama-sama sa ganap na pag-optimize, halimbawa), kung gayon
ang mga ito ay maaaring itala para sa susunod na henerasyon (at muling paggawa) nang direkta sa mga script.

pa on konstruksyon kapaligiran

default konstruksyon mga variable

Nabanggit natin, at ginamit, ang konsepto ng a konstruksyon kapaligiran, maraming beses sa
naunang mga pahina. Ngayon ay oras na upang gawin itong mas konkreto. Gamit ang mga sumusunod
pahayag:

$env = bagong cons();

isang sanggunian sa isang bago, default na kapaligiran sa pagtatayo ay nilikha. Naglalaman ito ng isang numero
ng mga variable ng konstruksiyon at ilang mga pamamaraan. Sa kasalukuyang pagsulat, ang default na listahan ng
Ang mga variable ng konstruksiyon ay tinukoy bilang mga sumusunod:

CC => 'cc',
CFLAGS => '',
CCCOM => '%CC %CFLAGS %_IFLAGS -c %< -o %>',
INCDIRPREFIX => '-Ako',
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',
ARFLAGS => 'r',
ARCOM => "%AR %ARFLAGS %> %<\n%RANLIB %>",
RANLIB => 'ranlib',
AS => 'bilang',
ASFLAGS => '',
ASCOM => '%AS %ASFLAGS %< -o %>',
LD => 'ld',
LDFLAGS => '',
PREFLIB => 'lib',
SUFLIB => '.a',
SUFLIBS => '.so:.a',
SUFOBJ => '.o',
ENV => { 'PATH' => '/ bin:/ usr / bin'},

Sa mga system ng Win32 (Windows NT), ang mga sumusunod na variable ng konstruksiyon ay na-override sa
default:

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

Ang mga variable na ito ay ginagamit ng iba't ibang pamamaraan na nauugnay sa kapaligiran, sa
partikular na anumang paraan na sa huli ay humihiling ng panlabas na utos ay papalit sa mga ito
mga variable sa panghuling utos, kung naaangkop. Halimbawa, ang paraan ng `Mga Bagay' ay tumatagal
isang bilang ng mga source file at inaayos upang makuha, kung kinakailangan, ang kaukulang bagay
mga file. Halimbawa:

Mga bagay na $env 'foo.c', 'bar.c';

Ito ay magsasaayos upang makagawa, kung kinakailangan, foo.o at bar.o. Ang utos na hinihingi ay simple
`%CCCOM', na lumalawak sa pamamagitan ng pagpapalit, sa naaangkop na panlabas na utos na kinakailangan
upang bumuo ng bawat bagay. Susuriin pa namin ang mga panuntunan sa pagpapalit sa ilalim ng `Command'
pamamaraan, sa ibaba.

Ang mga variable ng konstruksiyon ay ginagamit din para sa iba pang mga layunin. Halimbawa, ang `CPPPATH' ay
ginamit upang tukuyin ang isang colon-separated path ng mga isamang direktoryo. Ang mga ito ay inilaan upang maging
ipinasa sa C preprocessor at ginagamit din ng C-file scanning machinery sa
tukuyin ang mga dependency na kasangkot sa isang C Compilation. Mga variable na nagsisimula sa
underscore, ay nilikha sa pamamagitan ng iba't ibang pamamaraan, at dapat ay karaniwang ituring na ``panloob''
mga variable. Halimbawa, kapag tinawag ang isang pamamaraan na nangangailangan ng paglikha ng isang bagay
mula sa isang C source, ang variable na `_IFLAGS' ay nilikha: ito ay tumutugma sa `-I' switch
kinakailangan ng C compiler na kumatawan sa mga direktoryo na tinukoy ng `CPPPATH'.

Tandaan na, para sa anumang partikular na kapaligiran, ang halaga ng isang variable ay nakatakda nang isang beses, at pagkatapos
hindi kailanman i-reset (upang baguhin ang isang variable, dapat kang lumikha ng isang bagong kapaligiran. Ang mga pamamaraan ay ibinigay
para sa pagkopya ng mga umiiral na kapaligiran para sa layuning ito). Ang ilang mga panloob na variable, tulad ng
Ang `_IFLAGS' ay nilikha kapag hinihingi, ngunit kapag naitakda na, mananatiling maayos ang mga ito para sa buhay ng
kapaligiran.

Ang mga variable na `CFLAGS', `LDFLAGS', at `ARFLAGS' ay lahat ay nagbibigay ng lugar para sa pagpasa ng mga opsyon sa
ang compiler, loader, at archiver, ayon sa pagkakabanggit. Hindi gaanong malinaw, ang `INCDIRPREFIX'
Tinutukoy ng variable ang string ng opsyon na idaragdag sa simula ng bawat isama
direktoryo upang malaman ng tagatala kung saan hahanapin .h mga file. Katulad nito, ang
Tinutukoy ng variable ng `LIBDIRPREFIX' ang string ng opsyon na idaragdag sa simula ng
bawat direktoryo na dapat hanapin ng linker para sa mga aklatan.

Ang isa pang variable, `ENV', ay ginagamit upang matukoy ang kapaligiran ng system sa panahon ng pagpapatupad
ng isang panlabas na utos. Bilang default, ang tanging variable ng kapaligiran na nakatakda ay `PATH',
na siyang execution path para sa isang UNIX command. Para sa sukdulang reproducibility, dapat
talagang ayusin upang itakda ang iyong sariling landas ng pagpapatupad, sa iyong pinakamataas na antas Tayuan file (o
marahil sa pamamagitan ng pag-import ng naaangkop na pakete ng konstruksyon na may utos na Perl `use'). Ang
ang mga default na variable ay nilayon na alisin ka sa lupa.

Interpolating konstruksyon mga variable

Ang mga variable ng construction environment ay maaaring i-interpolate sa source at target na mga pangalan ng file
sa pamamagitan ng prefixing ng construction variable name na may `%'.

$env = bagong cons(
DESTDIR => 'mga programa',
SRCDIR => 'src',
);
Programa $env '%DESTDIR/hello', '%SRCDIR/hello.c';

Ang pagpapalawak ng mga variable ng konstruksiyon ay recursive--iyon ay, ang file pangalan(s) ay muling
pinalawak hanggang sa wala nang pamalit na maaaring gawin. Kung ang isang construction variable ay hindi
tinukoy sa kapaligiran, pagkatapos ay ang null string ay papalitan.

default konstruksyon pamamaraan

Kasama sa listahan ng mga default na paraan ng pagtatayo ang mga sumusunod:

Ang `bago' tagapagbuo

Ang `bago' na paraan ay isang Perl object constructor. Ibig sabihin, hindi ito hinihingi sa pamamagitan ng isang sanggunian
sa isang umiiral na kapaligiran sa pagtatayo sanggunian, ngunit, sa halip static, gamit ang pangalan
ng Perl pakete kung saan tinukoy ang tagabuo. Ang pamamaraan ay ginagamit tulad nito:

$env = bagong cons( );

Ang kapaligirang babalikan mo ay pinagpala sa package na `cons', na nangangahulugang gagawin nito
na nauugnay dito ang mga default na pamamaraan na inilarawan sa ibaba. Indibidwal na konstruksyon
Maaaring ma-override ang mga variable sa pamamagitan ng pagbibigay ng mga pares ng pangalan/halaga sa isang listahan ng override. Tandaan na
upang i-override ang anumang command environment variable (ibig sabihin, kahit ano sa ilalim ng `ENV'), kakailanganin mong gawin
i-override ang lahat ng ito. Malalampasan mo ang kahirapan na ito sa pamamagitan ng paggamit ng paraan ng `kopya' sa isang
umiiral na kapaligiran sa konstruksyon.

Ang `clone' paraan

Ang paraan ng `clone' ay lumilikha ng isang clone ng isang umiiral na kapaligiran ng konstruksiyon, at maaaring maging
tinatawag tulad ng sa sumusunod na halimbawa:

$env2 = $env1->clone( );

Maaari kang magbigay ng mga override sa karaniwang paraan upang lumikha ng ibang kapaligiran mula sa
orihinal. Kung gusto mo lang ng bagong pangalan para sa parehong kapaligiran (na maaaring makatulong kapag
pag-export ng mga kapaligiran sa mga umiiral na bahagi), maaari mo lamang gamitin ang simpleng pagtatalaga.

Ang `kopya' paraan

Kinukuha ng paraan ng `kopya' ang mga panlabas na tinukoy na mga variable ng konstruksiyon mula sa isang
kapaligiran at ibinabalik ang mga ito bilang isang listahan ng mga pares ng pangalan/halaga. Ang mga override ay maaari ding
sa kondisyon, kung saan, ang mga na-override na halaga ay ibabalik, kung naaangkop. Ang
ang ibinalik na listahan ay maaaring italaga sa isang hash, tulad ng ipinapakita sa prototype, sa ibaba, ngunit maaari rin
manipulahin sa ibang paraan:

%env = $env1->kopya( );

Ang halaga ng `ENV', na mismong isang hash, ay kinopya din sa isang bagong hash, kaya maaaring ito ay
nagbago nang walang takot na maapektuhan ang orihinal na kapaligiran. Kaya, halimbawa, kung ikaw talaga
gusto mong i-override lamang ang variable na `PATH' sa default na kapaligiran, maaari mong gawin ang
sumusunod:

%cons = new cons()->copy();
$cons{ENV}{PATH} = " ";
$cons = bagong cons(%cons);

Mag-iiwan ito ng anumang bagay na maaaring nasa default na kapaligiran ng pagpapatupad
hindi nagagambala.

Ang `I-install' paraan

Ang paraan ng `Install' ay nagsasaayos para sa mga tinukoy na file na mai-install sa tinukoy
direktoryo. Ang pag-install ay na-optimize: ang file ay hindi kinokopya kung maaari itong maiugnay. Kung
hindi ito ang nais na pag-uugali, kakailanganin mong gumamit ng ibang paraan upang mai-install ang
file. Tinatawag itong mga sumusunod:

I-install ang $env , ;

Tandaan na, habang ang mga file na mai-install ay maaaring arbitraryong pinangalanan, ang huli lamang
Ang bahagi ng bawat pangalan ay ginagamit para sa naka-install na target na pangalan. Kaya, halimbawa, kung ikaw
ayusin ang pag-install foo/bar in base, ito ay lilikha ng isang bar file sa base direktoryo (hindi
foo/bar).

Ang `InstallAs' paraan

Ang paraan ng `InstallAs' ay nagsasaayos para sa tinukoy na pinagmulan file(mga) ilalagay bilang ang
tinukoy na target file(s). Maramihang mga file ay dapat na tinukoy bilang isang listahan ng file. Ang
ang pag-install ay na-optimize: ang file ay hindi kinokopya kung maaari itong maiugnay. Kung hindi ito ang
ninanais na pag-uugali, kakailanganin mong gumamit ng ibang paraan upang i-install ang file. Ito ay
tinatawag ang mga sumusunod:

Gumagana ang `InstallAs' sa dalawang paraan:

Isang pag-install ng file:

InstallAs $env TgtFile, SrcFile;

Pag-install ng maramihang file:

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

O, kahit bilang:

@srcs = qw(src1 src2 src3);
@tgts = qw(tgt1 tgt2 tgt3);
InstallAs $env [@tgts], [@srcs];

Parehong dapat na magkapareho ang haba ng listahan ng target at mga source.

Ang `Precious' paraan

Ang `Precious' na paraan ay humihingi ng cons na huwag tanggalin ang tinukoy na file o listahan ng mga file dati
muling pagtatayo ng mga ito. Ito ay tinatawag bilang:

Precious ;

Ito ay lalong kapaki-pakinabang para sa pagpapahintulot sa mga incremental na update sa mga library o pag-debug
mga file ng impormasyon na ina-update sa halip na muling itinayong muli sa bawat oras. Cons ay pa rin
tanggalin ang mga file kapag tinukoy ang flag na `-r'.

Ang `Utos' paraan

Ang paraan ng `Command' ay isang catchall na paraan na maaaring magamit upang ayusin ang anumang panlabas
utos na tatawagin upang i-update ang target. Para sa command na ito, isang target na file at listahan ng
input ay ibinigay. Bilang karagdagan, ang isang construction command line, o mga linya, ay ibinibigay bilang a
string (ang string na ito ay maaaring may maraming mga command na naka-embed sa loob nito, na pinaghihiwalay ng bago
mga linya). Ang `Command' ay tinatawag na ganito:

Utos $env , , ;

Ang target ay ginawang nakadepende sa listahan ng mga input file na tinukoy, at ang mga input ay dapat
matagumpay na maitayo o hindi susubukan ng Cons na buuin ang target.

Sa loob ng utos ng konstruksiyon, ang anumang variable mula sa kapaligiran ng konstruksiyon ay maaaring
ipinakilala sa pamamagitan ng prefixing sa pangalan ng construction variable na may `%'. Ito ay recursive:
ang utos ay pinalawak hanggang sa wala nang pamalit na maaaring gawin. Kung isang construction
variable ay hindi tinukoy sa kapaligiran, pagkatapos ay ang null string ay papalitan. A
nadoble ang `%%' ay papalitan ng isang `%' sa construction command.

Mayroong ilang mga pseudo variable na papalawakin din:

%> Ang pangalan ng target na file (sa isang multi-target na command, ito ang palaging unang target
nabanggit).

%0 Pareho ng `%>'.

%1, %2, ..., %9
Ang mga ito ay tumutukoy sa una hanggang ikasiyam na input file, ayon sa pagkakabanggit.

%< Ang buong hanay ng mga input. Kung ang alinman sa mga ito ay ginamit saanman sa
kasalukuyang command line (sa pamamagitan ng `%1', `%2', atbp.), pagkatapos ay tatanggalin ang mga iyon mula sa
listahan na ibinigay ng `%<'. Isaalang-alang ang sumusunod na utos na makikita sa a konskript file
nasa pagsusulit direktoryo:

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

If tgt kailangang ma-update, pagkatapos ay magreresulta ito sa pagpapatupad ng
sumusunod sa mga utos, sa pag-aakalang walang remapping na naitatag para sa pagsusulit
direktoryo:

echo test/bar test/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

Ang alinman sa mga pseudo variable sa itaas ay maaaring sundan kaagad ng isa sa mga sumusunod
mga suffix para pumili ng bahagi ng pinalawak na pangalan ng path:

:a ang ganap na landas patungo sa pangalan ng file
:b ang direktoryo kasama ang pangalan ng file na tinanggal ng anumang suffix
:d ang direktoryo
:f ang pangalan ng file
:s ang suffix ng pangalan ng file
:F ang pangalan ng file na tinanggalan ng anumang suffix

Ang pagpapatuloy sa halimbawa sa itaas, ang `%<:f' ay lalawak sa `foo bar baz', at `%':d> ay
palawakin sa `pagsubok'.

Posibleng i-programmatically isulat muli ang bahagi ng command sa pamamagitan ng paglakip ng bahagi nito
sa pagitan ng `%[' at `%]'. Tatawagin nito ang construction variable na pinangalanan bilang unang salita
nakapaloob sa mga bracket bilang sanggunian ng Perl code; ang mga resulta ng tawag na ito ay gagamitin
upang palitan ang mga nilalaman ng mga bracket sa command line. Halimbawa, binigyan ng isang
kasalukuyang input file na pinangalanan tgt.in:

@keywords = qw(foo bar baz);
$env = new cons(X_COMMA => sub { join(",", @_) });
Command $env 'tgt', 'tgt.in', qq(
echo '# Keyword: %[X_COMMA @keywords %]' > %>
pusa %< >> %>
);

Ito ay isasagawa:

echo '# Keywords: foo,bar,baz' > tgt
pusa tgt.in >> tgt

Pagkatapos maganap ang pagpapalit, ang mga string ng puting espasyo ay na-convert sa mga solong blangko, at
ang nangungunang at sumusunod na puting espasyo ay tinanggal. Samakatuwid, hindi posible na magpakilala
variable length white space sa mga string na ipinasa sa isang command, nang hindi gumagamit ng ilan
uri ng shell quoting.

Kung ang isang multi-line na command string ay ibinigay, ang mga command ay isinasagawa nang sunud-sunod. Kung mayroon man
sa mga utos ay nabigo, pagkatapos ay wala sa iba ang naisakatuparan, at ang target ay hindi minarkahan bilang
na-update, ibig sabihin, ang isang bagong lagda ay hindi nakaimbak para sa target.

Karaniwan, kung magtagumpay ang lahat ng mga utos, at magbabalik ng zero status (o anumang platform-
tiyak na indikasyon ng tagumpay ay kinakailangan), pagkatapos ay isang bagong lagda ay naka-imbak para sa
target. Kung ang isang command ay maling nag-uulat ng tagumpay kahit na matapos ang isang pagkabigo, ang Cons ay gagawin
ipagpalagay na ang target na file na nilikha ng command na iyon ay tumpak at napapanahon.

Ang unang salita ng bawat command string, pagkatapos ng pagpapalawak, ay ipinapalagay na isang executable
utos ay tumingin sa `PATH' environment variable (na, naman, ay tinukoy ng
`ENV' construction variable). Kung ang utos na ito ay matatagpuan sa landas, ang target ay
depende dito: ang utos samakatuwid ay awtomatikong gagawin, kung kinakailangan. ito ay
posible na magsulat ng mga multi-part na command sa ilang mga shell, na pinaghihiwalay ng mga semi-colon. Tanging ang
ang unang command na salita ay nakasalalay, gayunpaman, kaya kung isusulat mo ang iyong mga string ng command
sa ganitong paraan, dapat ay tahasan kang mag-set up ng dependency (na may pamamaraang `Depends'), o
siguraduhin na ang utos na iyong ginagamit ay isang utos ng system na inaasahang magiging
magagamit. Kung hindi ito available, siyempre, magkakaroon ka ng error.

Kung ang anumang command (kahit isa sa loob ng isang multi-line command) ay nagsisimula sa `[perl]', ang natitira
ng command line na iyon ay susuriin ng tumatakbong Perl sa halip na ma-forked ng
kabibi. Kung may naganap na error sa pag-parse ng Perl o kung ang Perl expression ay nagbabalik ng 0 o
undef, ang utos ay ituturing na nabigo. Halimbawa, narito ang isang simple
utos na lumilikha ng isang file na `foo' nang direkta mula sa Perl:

$env = bagong cons();
Command $env 'foo',
qq([perl] open(FOO,'>foo');print FOO "hi\\n"; close(FOO); 1);

Tandaan na kapag ang command ay naisakatuparan, ikaw ay nasa parehong pakete tulad ng kapag ang Tayuan
or konskript nabasa ang file, kaya maaari mong tawagan ang mga function ng Perl na tinukoy mo sa parehong
Tayuan or konskript file kung saan lumalabas ang `Command':

$env = bagong cons();
sub create_file {
aking $file = shift;
open(FILE, ">$file");
i-print ang FILE "hi\n";
malapit (FILE);
1 bumalik;
}
Command $env 'foo', "[perl] &create_file('%>')";

Ang Perl string ay gagamitin upang bumuo ng lagda para sa hinangong file, kaya kung ikaw
baguhin ang string, ang file ay itatayong muli. Ang mga nilalaman ng anumang subroutine na tinatawag mo,
gayunpaman, ay hindi bahagi ng lagda, kaya kung babaguhin mo ang tinatawag na subroutine gaya ng
`create_file' sa itaas, ang target ay hindi muling itayo. Gumagamit ng Caveat.

Karaniwang nagpi-print ng command ang Cons bago ito isagawa. Ang pag-uugaling ito ay pinipigilan kung ang
ang unang character ng command ay `@'. Tandaan na maaaring kailanganin mong paghiwalayin ang `@' mula sa
ang pangalan ng command o i-escape ito upang maiwasan ang `@cmd' na magmukhang array sa Perl quote
mga operator na nagsasagawa ng interpolation:

# Ang unang command line ay hindi tama,
# dahil ang "@cp" ay mukhang isang array
# sa Perl qq // function.
# Gamitin ang pangalawang form sa halip.
Command $env 'foo', 'foo.in', qq(
@cp %< tempfile
@ cp tempfile %>
);

Kung mayroong mga shell meta character saanman sa pinalawak na command line, tulad ng `<',
`>', mga quote, o semi-colon, kung gayon ang utos ay talagang isasagawa sa pamamagitan ng paggamit ng isang
kabibi. Nangangahulugan ito na ang isang utos tulad ng:

cd foo

Ang mag-isa ay karaniwang mabibigo, dahil walang command na `cd' sa landas. Ngunit ang utos
string:

cd $<:d; tar cf $>:f $<:f

kapag pinalawak ay maglalaman pa rin ng shell meta character na semi-colon, at ang isang shell ay magiging
hinihikayat upang bigyang-kahulugan ang utos. Dahil ang `cd' ay binibigyang-kahulugan ng sub-shell na ito, ang command
ipapatupad gaya ng inaasahan.

Upang tumukoy ng command na may maraming target, maaari kang tumukoy ng reference sa isang listahan ng
mga target. Sa Perl, ang isang listahan ng sanggunian ay maaaring gawin sa pamamagitan ng paglakip ng isang listahan sa mga square bracket.
Samakatuwid ang sumusunod na utos:

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

ay maaaring gamitin sa isang kaso kung saan ang command na `gen' ay lumilikha ng dalawang file, pareho foo.h at foo.c.

Ang `Mga bagay' paraan

Ang paraan ng `Objects' ay nagsasaayos upang lumikha ng mga object file na tumutugma sa tinukoy
source file. Ito ay hinihingi tulad ng ipinapakita sa ibaba:

@files = Mga Bagay na $env ;

Sa ilalim ng Unix, nagtatapos ang mga source file sa .s at .c ay kasalukuyang sinusuportahan, at isasama-sama
sa isang pangalan ng parehong file na nagtatapos sa .o. Bilang default, ang lahat ng mga file ay nilikha sa pamamagitan ng pag-invoke
ang panlabas na utos na nagreresulta mula sa pagpapalawak ng `CCCOM' construction variable, na may
Ang `%<' at `%>' ay nakatakda sa source at object file, ayon sa pagkakabanggit (tingnan ang `Command' na paraan
para sa mga detalye ng pagpapalawak). Ginagamit din ang variable na `CPPPATH' kapag nag-scan ng mga source file
para sa mga dependency. Isa itong listahan ng mga pathname na pinaghihiwalay ng colon, at ginagamit din ito sa paggawa
ang construction variable `_IFLAGS,' na maglalaman ng naaangkop na listahan ng -`I'
mga opsyon para sa compilation. Ang anumang mga kamag-anak na pathname sa `CPPPATH' ay binibigyang kahulugan na kamag-anak
sa direktoryo kung saan nilikha ang nauugnay na kapaligiran sa pagtatayo (absolute
at mga top-relative na pangalan ay maaari ding gamitin). Ang variable na ito ay ginagamit ng `CCCOM'. Ang ugali
ng utos na ito ay maaaring mabago sa pamamagitan ng pagbabago ng alinman sa mga variable na interpolated
sa `CCCOM', gaya ng `CC', `CFLAGS', at, hindi direkta, `CPPPATH'. Posible rin na
palitan ang halaga ng `CCCOM', mismo. Bilang kaginhawahan, ibinabalik ng file na ito ang listahan ng
object filename.

Ang `Programa' paraan

Ang paraan ng `Program' ay nagsasaayos upang maiugnay ang tinukoy na programa sa tinukoy na bagay
mga file. Ito ay tinatawag sa sumusunod na paraan:

Programa $env , ;

Ang pangalan ng programa ay magkakaroon ng value ng construction variable na `SUFEXE' na idinagdag (ni
default, `.exe' sa Win32 system, wala sa Unix system) kung wala pa ang suffix
kasalukuyan.

Maaaring tukuyin ang mga source file sa halip ng mga object file--ang `Objects' na paraan ay magiging
hinihikayat upang ayusin ang pag-convert ng lahat ng mga file sa mga object file, at samakatuwid ang lahat ng
ang mga obserbasyon tungkol sa pamamaraang `Mga Bagay', sa itaas, ay nalalapat din sa pamamaraang ito.

Ang aktwal na pag-link ng programa ay hahawakan ng isang panlabas na utos na nagreresulta
mula sa pagpapalawak ng `LINKCOM' construction variable, na may `%<' na nakatakda sa object file sa
mai-link (sa pagkakasunud-sunod na ipinakita), at `%>' itakda sa target (tingnan ang paraan ng `Command'
para sa mga detalye ng pagpapalawak). Maaaring magtakda ang user ng mga karagdagang variable sa construction
kapaligiran, kabilang ang `LINK', upang tukuyin kung aling programa ang gagamitin para sa pag-link, `LIBPATH', isang
colon-separated list ng mga path sa paghahanap ng library, para gamitin sa mga detalye ng library ng
anyo -llib, at `LIBS', na tumutukoy sa listahan ng mga aklatan na ili-link (sa alinman -llib
form o bilang mga pathname lamang. Ang mga kaugnay na pathname sa parehong `LIBPATH' at `LIBS' ay binibigyang-kahulugan
kaugnay sa direktoryo kung saan nilikha ang nauugnay na kapaligiran sa pagtatayo
(maaari ding gamitin ang mga absolute at top-relative na pangalan). Awtomatikong nagse-set up ang Cons
dependencies sa anumang library na binanggit sa `LIBS': ang mga library na iyon ay itatayo bago
naka-link ang command.

Ang `Aklatan' paraan

Ang paraan ng `Library' ay nagsasaayos upang lumikha ng tinukoy na aklatan mula sa tinukoy na bagay
mga file. Ito ay hinihiling tulad ng sumusunod:

Library $env , ;

Ang pangalan ng library ay magkakaroon ng value ng `SUFLIB' construction variable na idinagdag (ni
default, `.lib' sa Win32 system, `.a' sa Unix system) kung ang suffix ay wala pa
kasalukuyan.

Maaaring tukuyin ang mga source file sa halip ng mga object file--ang `Objects' na paraan ay magiging
hinihikayat upang ayusin ang pag-convert ng lahat ng mga file sa mga object file, at samakatuwid ang lahat ng
ang mga obserbasyon tungkol sa pamamaraang `Mga Bagay', sa itaas, ay nalalapat din sa pamamaraang ito.

Ang aktwal na paglikha ng library ay hahawakan ng isang panlabas na utos na nagreresulta
mula sa pagpapalawak ng `ARCOM' construction variable, na may `%<' na nakatakda sa mga miyembro ng library (sa
ang order na ipinakita), at `%>' sa library na gagawin (tingnan ang `Command' na paraan para sa
mga detalye ng pagpapalawak). Ang gumagamit ay maaaring magtakda ng mga variable sa kapaligiran ng konstruksiyon na gagawin
nakakaapekto sa pagpapatakbo ng utos. Kabilang dito ang `AR', ang archive program na gagamitin,
`ARFLAGS', na maaaring gamitin upang baguhin ang mga flag na ibinigay sa program na tinukoy ng `AR',
at `RANLIB', ang pangalan ng isang archive index generation program, kung kinakailangan (kung ang partikular
kailangan ay hindi nangangailangan ng huling pag-andar, pagkatapos ay `ARCOM' ay dapat na muling tukuyin sa hindi
sanggunian `RANLIB').

Ang paraan ng `Library' ay nagbibigay-daan sa parehong library na matukoy sa maraming paraan
mga panawagan. Lahat ng nag-aambag na bagay mula sa lahat ng mga invocation (na maaaring mula sa
iba't ibang mga direktoryo) ay pinagsama at nabuo ng isang solong utos ng archive. Tandaan,
gayunpaman, na kung putulin mo ang isang build nang sa gayon ay bahagi lamang ng isang aklatan ang tinukoy, kung gayon lamang
ang bahaging iyon ng silid-aklatan ay mabubuo (ang iba ay mawawala!).

Ang `Module' paraan

Ang paraan ng `Module' ay isang kumbinasyon ng mga pamamaraan ng `Program' at `Command'. Imbes na
direktang bumubuo ng isang maipapatupad na programa, pinapayagan ka ng utos na ito na tukuyin ang iyong sarili
command upang aktwal na bumuo ng isang module. Ang pamamaraan ay ginagamit tulad ng sumusunod:

Module $env , , ;

Ang utos na ito ay kapaki-pakinabang sa mga pagkakataon kung saan nais mong lumikha, halimbawa, nang pabago-bago
load modules, o statically linked code library.

Ang `Depende' paraan

Ang pamamaraang `Depends' ay nagbibigay-daan sa iyo na tumukoy ng mga karagdagang dependency para sa isang target. Ito ay
tinawag tulad ng sumusunod:

Depende sa $env , ;

Maaari itong maging kapaki-pakinabang paminsan-minsan, lalo na sa mga kaso kung saan walang umiiral na scanner (o ay
maisusulat) para sa mga partikular na uri ng mga file. Karaniwan, ang mga dependency ay kinakalkula
awtomatikong mula sa kumbinasyon ng mga tahasang dependency na na-set up ng pamamaraan
invocation o sa pamamagitan ng pag-scan ng mga source file.

Maaaring tukuyin ang isang set ng magkaparehong dependency para sa maraming target gamit ang isang reference sa
isang listahan ng mga target. Sa Perl, ang isang listahan ng sanggunian ay maaaring gawin sa pamamagitan ng paglakip ng isang listahan sa parisukat
mga bracket. Samakatuwid ang sumusunod na utos:

Depende sa $env ['foo', 'bar'], 'input_file_1', 'input_file_2';

tumutukoy na pareho ang foo at bar nakadepende ang mga file sa nakalistang input file.

Ang `Huwag pansinin' paraan

Ang pamamaraang `Balewalain' ay nagbibigay-daan sa iyo na huwag pansinin ang tahasang mga dependency na ipinahihiwatig ng Cons dito
sariling. Ito ay hinihiling tulad ng sumusunod:

Huwag pansinin ;

Magagamit ito para maiwasan ang mga recompilations dahil sa mga pagbabago sa mga file ng header ng system o
mga utility na kilalang hindi makakaapekto sa mga nabuong target.

Kung, halimbawa, ang isang programa ay binuo sa isang NFS-mount na direktoryo sa maraming mga sistema na
may iba't ibang kopya ng stdio.h, ang mga pagkakaiba ay makakaapekto sa mga lagda ng lahat
nagmula sa mga target na binuo mula sa mga source file na `#include '. Ito ang magiging sanhi ng lahat
ang mga target na iyon na itatayong muli kapag nagbabago ng mga sistema. Kung ito ay hindi kanais-nais na pag-uugali,
pagkatapos ay aalisin ng sumusunod na linya ang mga dependencies sa stdio.h file:

Huwag pansinin ang '^/usr/include/stdio\.h$';

Tandaan na ang mga argumento sa pamamaraang `Balewalain' ay mga regular na expression, napakaespesyal
ang mga character ay dapat na itakas at maaaring naisin mong i-angkla ang simula o dulo ng
expression na may mga character na `^' o `$'.

Ang `Asin' paraan

Ang paraan ng `Asin' ay nagdaragdag ng pare-parehong halaga sa pagkalkula ng lagda para sa bawat hinango
file. Ito ay hinihiling tulad ng sumusunod:

Salt $string;

Ang pagbabago sa halaga ng Salt ay pipilitin ang isang kumpletong muling pagtatayo ng bawat nagmula na file. Ito ay maaaring
ginagamit upang pilitin ang mga muling pagtatayo sa ilang gustong mga pangyayari. Halimbawa,

Asin `uname -s`;

Pipilitin ang isang kumpletong muling pagtatayo ng bawat nagmula na file sa tuwing naka-on ang operating system
kung saan ang build ay ginanap (tulad ng iniulat ng `uname -s') mga pagbabago.

Ang `UseCache' paraan

Ang paraan ng `UseCache' ay nagtuturo sa Cons na magpanatili ng cache ng mga nagmula na file, na ibabahagi
sa magkakahiwalay na mga puno ng pagtatayo ng parehong proyekto.

UseCache("cache/ ") ⎪⎪ warn("hindi nahanap ang direktoryo ng cache");

Ang `SourcePath' paraan

Ibinabalik ng `SourcePath' mathod ang tunay na pangalan ng path ng pinagmulan ng isang file, bilang laban sa
pangalan ng path sa loob ng isang build directory. Ito ay hinihiling tulad ng sumusunod:

$path = SourcePath ;

Ang `ConsPath' paraan

Ang paraan ng `ConsPath' ay nagbabalik ng true kung ang ibinigay na landas ay isang derivable file, at nagbabalik
undef (false) kung hindi man. Ito ay hinihiling tulad ng sumusunod:

$result = ConsPath ;

Ang `SplitPath' paraan

Ang paraan ng `SplitPath' ay naghahanap ng maraming pangalan ng path sa isang string na pinaghihiwalay ng default
path separator para sa operating system (':' sa UNIX system, ';' sa Windows NT), at
ibinabalik ang ganap na kwalipikadong mga pangalan. Ito ay hinihiling tulad ng sumusunod:

@paths = SplitPath ;

Ang paraan ng `SplitPath' ay magko-convert ng mga pangalan na may prefix na '#' sa naaangkop na top-level na build
pangalan (nang walang '#') at magko-convert ng mga kamag-anak na pangalan sa mga pangalan sa pinakamataas na antas.

Ang `DirPath' paraan

Ibinabalik ng paraan ng `DirPath' ang build path pangalan(mga) ng isang direktoryo o listahan ng mga direktoryo.
Ito ay hinihiling tulad ng sumusunod:

$cwd = DirPath ;

Ang pinakakaraniwang gamit para sa paraan ng `DirPath' ay:

$cwd = DirPath '.';

upang kunin ang landas patungo sa kasalukuyang direktoryo ng isang subsidiary konskript file.

Ang `FilePath' paraan

Ibinabalik ng paraan ng `FilePath' ang build path pangalan(mga) ng isang file o listahan ng mga file. Ito ay
tinawag tulad ng sumusunod:

$file = FilePath ;

Ang `Tulong' paraan

Tinutukoy ng paraan ng `Help' ang text ng tulong na ipapakita kapag tinawag ng user ang `cons
-h'. Magagamit ito para magbigay ng dokumentasyon ng mga partikular na target, value, build
mga opsyon, atbp. para sa build tree. Ito ay hinihiling tulad ng sumusunod:

Tulong ;

Ang paraan ng `Tulong' ay maaari lamang tawagin nang isang beses, at dapat ay karaniwang tukuyin sa itaas-
antas Tayuan file.

Pagpapalawak Kahinaan

Sobra konstruksyon mga variable

Mayroong ilang mga paraan ng pagpapalawak ng Cons, na nag-iiba sa antas ng kahirapan. Ang pinakasimple
Ang pamamaraan ay upang tukuyin ang iyong sariling kapaligiran sa pagtatayo, batay sa default na kapaligiran,
ngunit binago upang ipakita ang iyong mga partikular na pangangailangan. Ito ay kadalasang sapat para sa C-based
mga aplikasyon. Maaari mong gamitin ang `bagong' constructor, at ang `clone' at `kopya' na pamamaraan upang
lumikha ng mga hybrid na kapaligiran. Ang mga pagbabagong ito ay maaaring maging ganap na malinaw sa pinagbabatayan
konskript file.

Pagdaragdag bago pamamaraan

Para sa bahagyang mas mahirap na mga pagbabago, maaaring naisin mong magdagdag ng mga bagong pamamaraan sa `cons'
pakete. Narito ang isang halimbawa ng isang napakasimpleng extension, `InstallScript', na nag-i-install ng a
tcl script sa isang hiniling na lokasyon, ngunit in-edit muna ang script upang ipakita ang isang platform-
dependent path na kailangang mai-install sa script:

# cons::InstallScript - Lumikha ng isang bersyon na nakasalalay sa platform ng isang shell
# script sa pamamagitan ng pagpapalit ng string na ``#!your-path-here'' ng partikular na platform
# landas $BIN_DIR.

sub cons::InstallScript {
my ($env, $dst, $src) = @_;
Utos $env $dst, $src, qq(
sed s+your-path-here+$BIN_DIR+ %< > %>
chmod oug+x %>
);
}

Pansinin na ang paraang ito ay direktang tinukoy sa package na `cons' (sa pamamagitan ng prefixing ng pangalan
may `cons::'). Ang pagbabagong ginawa sa ganitong paraan ay makikita sa buong mundo sa lahat ng kapaligiran,
at maaaring tawaging tulad ng sa sumusunod na halimbawa:

InstallScript $env "$BIN/foo", "foo.tcl";

Para sa isang maliit na pagpapabuti sa pangkalahatan, ang variable na `BINDIR' ay maaaring ipasa bilang isang
argumento o kinuha mula sa kapaligiran ng konstruksiyon--bilang `%BINDIR'.

Sobra pamamaraan

Sa halip na idagdag ang pamamaraan sa puwang ng pangalan ng `cons', maaari mong tukuyin ang isang bagong pakete
na nagmamana ng mga umiiral nang pamamaraan mula sa package na `cons' at nag-o-override o nagdaragdag ng iba. Ito
maaaring gawin gamit ang mga mekanismo ng pamana ni Perl.

Ang sumusunod na halimbawa ay tumutukoy sa isang bagong package `cons::switch' na nag-o-override sa pamantayan
Paraang `Library'. Ang na-override na paraan ay bumubuo ng mga naka-link na module ng library, sa halip na library
mga archive. Isang bagong constructor ang ibinigay. Mga kapaligirang nilikha gamit ang constructor na ito ay
magkaroon ng bagong paraan ng aklatan; ang iba ay hindi.

package cons::switch;
MAGSIMULA {@ISA = 'cons'}

sub new {
shift;
pagpalain ang mga bagong kahinaan(@_);
}

sub Library {
my($env) = shift;
my($lib) = shift;
my(@objs) = Mga Bagay $env @_;
Command $env $lib, @objs, q(
%LD -r %LDFLAGS %< -o %>
);
}

Maaaring gamitin ang pagpapaandar na ito tulad ng sa sumusunod na halimbawa:

$env = bagong cons::switch(@overrides);
...
Library $env 'lib.o', 'foo.c', 'bar.c';

Pagsusumikap Kahinaan

Ang utos na `cons' ay karaniwang ginagamit mula sa ugat ng build tree. A Tayuan file
dapat na umiiral sa direktoryo na iyon. Kung ang `-f' argument ay ginamit, pagkatapos ay isang kahaliling Tayuan
file ay maaaring gamitin (at, posibleng, isang kahaliling ugat, dahil ang `cons' ay cd sa Tayuan
file na naglalaman ng direktoryo).

Kung ang `cons' ay hinihingi mula sa isang anak ng ugat ng build tree na may `-t' argument, ito
ay lalakad sa hierarchy ng direktoryo na naghahanap ng a Tayuan file. (Ang isang kahaliling pangalan ay maaaring
matukoy pa rin gamit ang `-f'.) Ang mga target na ibinigay sa command line ay mababago
upang maging kamag-anak sa natuklasan Tayuan file. Halimbawa, mula sa isang direktoryo na naglalaman ng
isang pinakamataas na antas Tayuan file, ang sumusunod na invocation:

% cd libfoo/subdir
% cons -t target

ay eksaktong katumbas ng:

% cons libfoo/subdir/target

Kung mayroong anumang mga target na `Default' na tinukoy sa hierarchy ng direktoryo Tayuan or
konskript file, tanging ang mga default na target sa o sa ibaba ng direktoryo kung saan `cons -t'
ay itinayo.

Ang utos ay hinihingi tulad ng sumusunod:

cons --

saan argumento maaaring alinman sa mga sumusunod, sa anumang pagkakasunud-sunod:

target Buuin ang tinukoy na target. Kung target ay isang direktoryo, pagkatapos ay recursively bumuo
lahat sa loob ng direktoryo na iyon.

+ pattern Limitahan ang konskript mga file na itinuring sa mga tumutugma lamang huwaran, Kung saan ay
isang regular na expression ng Perl. Maramihang `+' na argumento ang tinatanggap.

pangalan=
Sets pangalan upang pahalagahan Val sa `ARG' hash na naipasa sa pinakamataas na antas Tayuan file.

`-cc' Ipakita ang utos na ipapatupad sana, kapag kinukuha mula sa cache. Hindi
indikasyon na ang file ay nakuha na ay ibinigay; ito ay kapaki-pakinabang para sa
pagbuo ng mga build log na maihahambing sa mga totoong build log.

`-cd' Huwag paganahin ang lahat ng pag-cache. Huwag kunin mula sa cache o mag-flush sa cache.

`-cr' Bumuo ng mga dependency sa random na pagkakasunud-sunod. Ito ay kapaki-pakinabang kapag bumubuo ng maramihang
mga katulad na puno na may pinaganang caching.

`-cs' I-synchronize ang mga umiiral nang build target na napatunayang up-to-date sa cache.
Ito ay kapaki-pakinabang kung ang pag-cache ay hindi pinagana sa -cc o kamakailan lamang pinagana
gamit ang UseCache.

`-d' Paganahin ang pag-debug ng dependency.

`-f'
Gamitin ang tinukoy na file sa halip na Tayuan (ngunit baguhin muna sa naglalaman
direktoryo ng file).

`-h' Magpakita ng lokal na mensahe ng tulong sa kasalukuyang build kung ang isa ay tinukoy, at lumabas.

`-k' Magpatuloy hangga't maaari pagkatapos ng mga pagkakamali.

`-o'
Basahin ang override na file file.

`-p' Ipakita ang mga produktong pang-konstruksyon sa mga tinukoy na puno. Walang pagtatangka na bumuo.

`-pa' Ipakita ang mga produktong pang-konstruksyon at mga nauugnay na aksyon. Walang pagtatangka na bumuo.

`-pw' Ipakita ang mga produkto at kung saan tinukoy ang mga ito. Walang pagtatangka na bumuo.

`-q' Huwag maging verbose tungkol sa Pag-install at Pag-alis ng mga target.

`-r' Alisin ang mga produktong construction na nauugnay sa . Walang pagtatangka na bumuo.

`-R'
Maghanap ng mga file sa Repos. Maramihang -R Repos Hinahanap ang mga direktoryo sa
tinukoy ang order.

`-t' Traverse up ang directory hierarchy na naghahanap ng a Tayuan file, kung wala
sa kasalukuyang direktoryo. Ang mga target ay babaguhin upang maging kaugnay sa
Tayuan file.

`-v' Ipakita ang bersyon ng `cons' at ipagpatuloy ang pagproseso.

`-V' Ipakita ang bersyon ng `cons' at lumabas.

`-wf'
Isulat ang lahat ng filename na isinasaalang-alang file.

`-x' Magpakita ng mensahe ng tulong na katulad nito, at lumabas.

at construct-args maaaring maging anumang mga argumento na nais mong iproseso sa Tayuan file.
Tandaan na dapat mayroong a -- paghihiwalay ng mga argumento sa cons at ang mga argumento na ikaw
gustong iproseso sa Tayuan file.

Pagpoproseso ng construct-args maaaring gawin ng anumang karaniwang pakete tulad ng Getopt o nito
variant, o anumang package na tinukoy ng user. cons papasa sa construct-args as @ARGV at
ay hindi magtatangka na bigyang-kahulugan ang anuman pagkatapos ng --.

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

ipapasa ang sumusunod sa cons

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

at ang mga sumusunod, sa pinakamataas na antas Tayuan file bilang @ARGV

-c pagsubok -f DEBUG

Tandaan na `cons -r .' ay katumbas ng isang buong recursive na `make clean', ngunit nangangailangan ng hindi
suporta sa Tayuan file o anuman konskript mga file. Ito ay pinakakapaki-pakinabang kung ikaw ay
pag-compile ng mga file sa mga source na direktoryo (kung ihihiwalay mo ang magtayo at i-export mga direktoryo,
pagkatapos ay maaari mo lamang alisin ang mga direktoryo).

Ang mga opsyon na `-p', `-pa', at `-pw' ay lubhang kapaki-pakinabang para gamitin bilang tulong sa pagbabasa
script o pag-debug sa kanila. Kung gusto mong malaman kung anong script ang ini-install i-export/isama/foo.h,
halimbawa, i-type lang:

% cons -pw export/include/foo.h

paggamit at pagsulat pagpapasustento Scanner

Ang QuickScan ay nagbibigay-daan sa mga simpleng target-independent na scanner na i-set up para sa mga source file. Tanging
ang isang QuickScan scanner ay maaaring iugnay sa anumang ibinigay na source file at environment.

Ang QuickScan ay hinihimok tulad ng sumusunod:

QuickScan CONSENV CODEREF, FILENAME [, PATH]

Ang subroutine na isinangguni ng CODEREF ay inaasahang magbabalik ng listahan ng mga filename na kasama
direkta sa pamamagitan ng FILE. Ang mga filename na ito ay, sa turn, ay mai-scan. Ang opsyonal na argumento ng PATH
nagbibigay ng lookup path para sa paghahanap ng FILENAME at/o mga file na ibinalik ng ibinigay ng user
subroutine. Ang PATH ay maaaring isang sanggunian sa isang hanay ng mga pangalan ng lookup-directory, o a
string ng mga pangalan na pinaghihiwalay ng character ng separator ng system (':' sa UNIX system, ';' on
Windows NT).

Ang subroutine ay tinatawag nang isang beses para sa bawat linya sa file, na may $_ na nakatakda sa kasalukuyang linya.
Kung ang subroutine ay kailangang tumingin sa mga karagdagang linya, o, sa bagay na iyon, ang buong file,
pagkatapos ay maaari nitong basahin ang mga ito mismo, mula sa filehandle na SCAN. Maaari rin nitong wakasan ang loop, kung
alam nito na walang karagdagang isamang impormasyon ang magagamit, sa pamamagitan ng pagsasara ng filehandle.

May ibinigay man o hindi path ng paghahanap, susubukan muna ng QuickScan na hanapin ang file
kaugnay sa kasalukuyang direktoryo (para sa pinakamataas na antas ng file na direktang ibinibigay sa QuickScan),
o mula sa direktoryo na naglalaman ng file na nag-refer sa file. Ito ay hindi masyadong
pangkalahatan, ngunit tila sapat na mabuti--lalo na kung mayroon kang karangyaan sa pagsulat ng iyong sarili
mga utility at maaaring kontrolin ang paggamit ng landas sa paghahanap sa karaniwang paraan. Sa wakas, ang
Ang path ng paghahanap ay, sa kasalukuyan, nakahiwalay sa colon. Maaaring hindi nito mapasaya ang kampo ng NT.

Narito ang isang tunay na halimbawa, kinuha mula sa isang Tayuan file dito:

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

[TANDAAN na ang form na `$env->QuickScan ...' at `$env->Command ...' ay hindi dapat
kinakailangan, ngunit, sa ilang kadahilanan, ay kinakailangan para sa partikular na panawagan. Lumilitaw ito
upang maging isang bug sa Perl o isang hindi pagkakaunawaan sa aking bahagi; ang istilo ng invocation na ito ay hindi
palaging mukhang kailangan.]

Hahanapin nito ang lahat ng pangalan ng form .smf sa file. Ibabalik nito ang mga pangalan kahit na
sila ay matatagpuan sa loob ng mga komento, ngunit iyon ay OK (ang mekanismo ay pagpapatawad ng mga karagdagang file;
binabalewala lang sila sa pag-aakalang mapapansin ang nawawalang file kapag ang
programa, sa halimbawang ito, smfgen, ay aktwal na tinatawag).

Ang isang scanner ay ginagamit lamang para sa isang ibinigay na source file kung ito ay kinakailangan ng ilang target sa
puno. Isang beses lang ito na-invoke para sa isang ibinigay na source file.

Narito ang isa pang paraan upang bumuo ng parehong scanner. Gumagamit ito ng isang tahasang sanggunian ng code,
at din (hindi kinakailangan, sa kasong ito) binabasa ang buong file mismo:

sub myscan {
my(@includes);
gawin
push(@includes, /\b\S*?\.smf\b/g);
} habang ;
@kasama ang
}

Tandaan na ang pagkakasunud-sunod ng loop ay baligtad, kasama ang pagsubok ng loop sa dulo. Ito ay
dahil nabasa na ang unang linya para sa iyo. Maaaring i-attach ang scanner na ito sa isang source
file ni:

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

SUPORTA AT MGA SAKAL

Ang mga kahinaan ay pinananatili ng komunidad ng gumagamit. Upang mag-subscribe, magpadala ng mail sa cons-discuss-
[protektado ng email] may katawan sumuskribi.

Mangyaring iulat ang anumang mga mungkahi sa pamamagitan ng [protektado ng email] listahan ng pag-mail.

Gumamit ng cons online gamit ang mga serbisyo ng onworks.net