Zakončení seriálu aneb co se do minulých dílů nevešlo a mělo by
6.9.2010 00:00 | Radim Kolář | přečteno 6860×
Pokud máme několik vlastních testů tak brzy zjistíme že ukládat je do souboru SConstruct je dost nepraktické. Zabírají tam místo, při editaci souboru je musíte scrollováním přeskakovat a zbytečně znepřehledňují situaci. Mnohem lepší je ukládat všechny testy do samostatných souborů a pak je importovat. Toho můžeme v SCons dosáhnout několika způsoby protože v SCons můžeme použít pro tento účel nástroje Pythonu.
První možností je použití příkazu exec. Je to sice takové sparťanské vyžadující více lidské práce, ale zase si můžeme import mechanizmus ručně doupravit a kupříkladu si automaticky stahovat nejnovější verze testů z VCS. Test taky můžeme přidat do hlavní knihovny Pythonu podadresář site-packages jako každý jiný Python kód který chceme sdílet v rámci naší instalace Pythonu. Je to vhodné pokud chceme sdílet testy napříč projekty. Poslední a nejpoužívanější variantou je umístit adresář site_scons do hlavního adresáře projektu. Tento adresář je automaticky přidán do Python import path a tak můžeme scripty a testy z tohoto adresáře importovat standardní Python directivou import. Pro zjednodušení nepoužívám namespace ale syntax from soubor import funkce. Doporučuji používat jeden soubor na jeden test a do souboru dovnitř si poznačit verzi testu nebo datum jeho poslední změny aby byla možná ruční synchronizace těchto testů napříč projekty.
Některé složitější knihovny používají pro snažší integraci do build systému balík pkg-config. Tento program předá systému pro sestavování přepínače C preprocesoru a seznam knihoven které je potřeba nalinkovat pro správnou funkci programů používajících danou knihovnu. Podpora v SCons je velmi luxusní a snadno použitelná. Pro načtení přepínačů do prostředí projektu stačí jen zavolat:
env.ParseConfig("pkg-config x11 --cflags --libs")
SCons umí ukládat a načítat proměnné ze souboru. Je to alternativa k argumentům na příkazové řádce. V praxi se to moc nepoužívá, protože se to nedá automatizovat a ruční editace souboru se seznamem proměnných zbytečně zdržuje. Tato funkcionalita by se neměla nikdy používat jako náhrada cache testů - to jest načíst konfiguraci a uložit hodnoty proměnných do souboru. Pokud totiž dojde je změně prostředí tak ztrácíte možnost tuto změnu automaticky zaregistrovat a přenastavit build prostředí, což vede ke zbytečných chybám. Příklad na použití této funkcionality najdete zde.
Argumenty příkazového řádku jsou nejpoužívanějším prostředkem předávání nastavení. Jedná se o páry klíč=hodnota, které uvedeme na příkazové řádce. V SCons scriptu se k nim dostaneme v pomocí ARGUMENTS.get(jméno argumentu, default hodnota). Na příklad se podívejte zde.
Další předností SCons je vestavěný systém pro cachování přeložených objektů. Pracuje podobně jako CCache ale opadá problém s integrací. Použití této funkcionality je velmi snadné. Stačí jen zavolat CacheDir(adresář do kterého můžeme zapisovat) a SCons se o zbytek postará sám. Soubory jsou ověřovány na aktuálnost pomocí MD5 signatur. Pokud máme otisk zdrojového souboru v cache společně s výstupem tak není třeba kompilovat, objekt se nahraje z cache. Použití této funkcionality velmi zrychlí překompilování velkých C++ projektů. Pokud sdílíme cache napříč projekty tak se doporučuje sestavovat objekty v náhodném pořadí scons --random aby procesy CC nepřekládaly jeden program vícekrát současně.
Protože SCons pracuje s projektem jako s celkem a nikoliv po adresářích jako make tak je velmi jednoduché správně seřadit práci kompilátoru tak aby bylo možné překládat více objektů současně. Je to výhodné jednak na vícejádrových procesorech kde nastává velmi výrazné zvýšení výkonu, ale také se to hodí na vykrytí míst kde kompilátor čeká na načítání souborů z disku, protože zatímco jeden proces čeká, druhý může překládat. Používá se to stejně jako u utility make scons -j 10 kde argument udává maximální povolený počet souběžných kompilací. Velikost argumentu stanovíme experimentálně. Pokud použijeme příliš velkou hodnotu a dojde nám operační paměť tak se dojde k výraznému prodloužení doby kompilace. Pro usnadnění použití abychom ho nemuseli při každém vyvolání SCons uvádět na příkazové řádce uložíme tento argument do proměnné environmentu SCONSFLAGS.
U větších projektů nechceme aby se nám míchaly zdrojové a cílové soubory. Dosáhneme toho pomocí funkce VariantDir které předáme dva parametry - kam soubory ukládat a z jakého podstromu projektu.
VariantDir('build', 'src')
Toto je konec seriálu o nástroji pro sestavování software SCons. Některé jeho vlastnosti jsme neprobírali a proto v případě zájmu čtenářů v komentářích pod článkem mohu ještě tak 2 dily dopsat. Pokud se jedná o kompilování C či C++ kódu tak by jste měli být tímto seriálem vybaveni velmi dobře pro většinu běžných problémů na které při použití SCons narazíte.
Projděte si celý seriál a použijte SCons ve svých projektech jako náhradu Gnu make, Autoconf, Automake nebo i novějších systémů jako je třeba Jam od Perforce. Taky je dobré si projít porovnání SCons s ostatními systémy, protože v současné době narůstá jednak počet projektů co se od GNU Autotools odklání a jednak počet projektů co se snaží GNU Autotools nahradit. Pro nový projekt bych dnes již Autotools nepoužil, po mnohaleté zkušenosti s nimi si nejsem jist zda náhodou nezpůsobují více problémů než řeší.
Asi nejznámější jejich náhrada je CMake, který ale závisí na gnu make a proto nemůže nabízet takovou integraci a funkcionalitu jako má SCons. SCons je velmi elegantní a snadno použitelný systém, který se dá velmi dobře přizpůsobit na míru, což oceníte hlavně u větších projektů. Často se také o SCons říká, že to není program ale framework. To je z části pravda a je to dobře, protože každý větší projekt má svůj poměrně specifický build systém a v SCons nejste vázáni konvencemi jako třeba v případě Automake a můžete si proto ničím nerušeni build naprogramovat tak jak je potřeba namísto ohýbání hotového uzavřenějšího systému.
Nejčastější věc co se SCons vytýká je jeho rychlost. SCons používá MD5 signatury a proto test který program se změnil a který ne nějakou dobu potrvá. Musím říci že mne většina komentářů ohledně rychlosti SCons kterou lidé považují za nepoužitelnou překvapuje. V tomto blogu v komentáři si můžete přečíst komentář člověka kterému se nelíbí že u SCons trvá u jeho velkého C++ projektu asi 10 sekund než začne kompilovat. Když si vezmete počet kompilací za hodinu, kterých moc není, a vynásobíte je dobou o kterou je SCons pomalejší než make tak musíte tuto dobu porovnat s dobou strávenou nad tím, že make vyrobil nekorektní build nebo že bylo potřeba udělat clean all a kompletní rekompilaci aby to make zvládnul správně sestavit.