V prvním díle jsme se seznámili s nástrojem SCons. Dnes se na něj podíváme
trochu blíž.
7.7.2005 07:00 | Radim Kolář | czytane 9303×
RELATED ARTICLES
KOMENTARZE
Předmluva
Ačkoliv jsem se s SCons seznámil a líbil se
mi jeho přístup k projektu jako k celku, byl jsem líný se ho pořádně učit a
používat. Pod pojmem používat si představte předělávání stávající autotools konfigurace do
SConsu. Znáte to, když to víceméně funguje, nevrtejte moc do toho.
V té době jsem zrovna dokončoval jeden z FSP
souvisejících projektů. Jednalo se o knihovnu fsplib, která zapouzdřuje FSP protokol do libc-like
API. Knihovna je velmi malá, zdrojové texty mají cca 35 kB. Velice mně
překvapilo, že po použití GNU Autotoolů, konktétně libtool, autoconf a automake nabobtnal výsledný
tarball tak, že po zakomprimování měl 250 kB. To rozhodlo.
SConstruct
Tím, čím je pro GNU Autotools soubor configure.ac, je pro SCons soubor
SConstruct. Tento soubor je umístěn v hlavním adresáři projektu a je souborem,
který hledá SCons po spuštění. Pokud se nenacházíme v hlavním adresáři
projektu, lze scons spustit s přepínačem -u, který zajistí hledání tohoto
souboru směrem vzhůru v adresářové struktuře. Tuto volbu budete určitě
často používat. Každý projekt musí mít právě jeden SConstruct.
SConscript
Jelikož je z hlediska údržby nepraktické mít všechno uložené v centrálním
souboru, jsou tu SConscript soubory. Tyto soubory nejsou hledány implicitně,
ale je nutné SCons říci v kterých adresářích se mají hledat. Pokud soubor
SConstript neexistuje, není to na rozdíl od chybějícího SConstruct fatální
chyba.
Soubory SConstript a SConstruct jsou shodné co do syntaxe a použití. Je tedy
jedno, do kterého z nich námi požadovaný příkaz uvedeme. Běžná praxe je
používat SConstruct jako náhradu configure.ac a SConstript jako náhradu
Makefile.am.
scons
Nástroj scons se spouští příkazem scons. Pokud pomineme utilitu sconsign
sloužící k human readable výpisu .sconsign souborů, je to také jediný program, který je v tomto systému obsažen.
Syntaxe příkazu scons se podobá syntaxi příkazu make. Toto nám usnadní jeho
naučení, jelikož od nynějška budeme psát místo make scons. SCons tedy přejímá
nejpopulárnější přepínače utility make s přihlednutí k rozšířením zavedeným v
GNU Make.
Nejčastěji budeme používat: -j pro paralelní buildy, -k pro sestavení co
největší části buildu v případě kompilační chyby, -i pro ignorování veškerých
chyb a -n pro běh naprázdno. Kromě optionů jsou podporovány i volby scons
target a scons proměnná=hodnota.
Zajímavá je volba -c. Tato volba provede clean k zadanému nebo implicitnímu
targetu. Specialitou SCons je, že cleanup akce nemusí být na rozdíl od make
nikde specifikovány. Jelikož SCons ví, které soubory z kterých vzniknou při
kompilaci, umí tyto informace zužitkovat a provést obrácenou akci.
Sledování aktuálnosti souborů
SCons nevyužívá na rozdíl od make datum poslední modifikace souboru, místo toho
používá jeho MD5 signaturu. Pokud používáte systémy pro správu verzí, které při
checkoutu nenastavují datum poslední modifikace podle vzdáleného systému
(například GNU Arch nebo Subversion) rozhodně to oceníte zejména v případě
hlavičkových souborů, které často lavinovitě zaviní zbytečnou rekompilaci
celého projektu.
Kromě časových značek nebo obsahových signatur je nutné i sledování
závislostí mezi jednotlivými soubory. Pokud zná SCons použitý programovací
jazyk zdrojového souboru, je schopno automaticky detekovat jeho závislosti.
Pokud ne, je nutné závislosti specifikovat explicitně nebo naučit SCons
nový programovací jazyk, což je kupodivu velmi snadná úloha. Ve většině
případů na to stačí méně než 2kB Python kódu. Standardně je podporováno C, C++, D, Fortran a IDL.
.sconsign
Závislosti, časové značky a MD5 signatury jsou ukládány do souborů .sconsign,
které najdete v každém adresáři obhospodařovaném systémem SCons. Tyto soubory
jsou binární a jak již bylo zmíněno, utilita pro jejich vypsání v textovém
tvaru se nazývá sconsign. Ještě by stálo zato poznamenat, že z .sconsign nejsou
automaticky odstraněny záznamy o již neexistujících souborech.
Rychlost SCons
Na závěr bych ještě cosi poznamenal o rychlosti SCons. Pokud srovnáte
SCons s make zjistíte, že je SCons několikanásobně pomalejší. Je to dáno
několika faktory: SCons je naprogramováno v interpretovaném programovacím
jazyce a kontroluje u souborů i obsah, nejen časové značky. Místo benchmarků
SCons vs GNU Make je nutné změnit pohled na věc.
Vývoj programů probíhá obvykle v cyklu: edit, compile, test, debug. Délka
tohoto cyklu je řekněme 20 minut. Doba, kterou z tohoto cyklu zabere
buildovací utilita (nepléct s časem stráveným kompilátorem), tvoří zanedbatelný
zlomek tohoto času. Naproti tomu po půlroce používání SCons mohu tvrdit, že
se přechod Autotools -> SCons rozhodně vyplatil, jelikož se snížil čas
potřebný k obhospodařování build systému, který se navíc u složitějších
projektů velmi špatně debugoval.