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ář | přečteno 9099×
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.
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.
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.
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.
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.
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.
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.