Předmluva

O projektu SCons jsem věděl již dávno. Zařadil jsem ho mezi slibně se vyvíjející projekty a čekal, co ze z něj časem vyvine. Přesněji řečeno, čekal jsem až a zda ho začnou používat Open Source projekty. V roce 2004 se konečně začal SCons více používat jako build systém pro Open Source projekty. Zdetekoval jsem několik projektů, které přešly z GNU autotools na SCons. SCons začal být používán i v komerční sféře, podle slov autorů je to build systém pro hru Doom 3. Pravděpodobně nejznámější Open Source projekty používající SCons jsou Blender a jeho spřátelený renderer Yafray.

Nevýhody GNU Autotools

GNU Autotools se skládají ze tří hlavních částí: Autoconf, Automake a Libtool. Programátoři je proklínají sice všechny, ale pokud bych je měl seřadit podle jejich neoblíbenosti tak 1. automake, 2. libtool, 3. autoconf. To však neznamená, že se nepoužívají. Právně naopak. Protože tyto nástroje odvedou i přes své nedostatky dobré služby, je po zanadávání si obvykle snadnější svůj projekt přizpůsobit představám Autotůlů než je zcela ignorovat a obstarat si ekvivaletní věci ve vlastní režii. Některé nevýhody těchto nástrojů najdete popsané na Fresh meatu. Nevýhod mají opravdu mnoho, uvedu zde jen ty základní.

Koncept

• Základní koncept t.j. generování Makefile pomocí standardních systémových utilit (shell,sed,...) není optimální. Lepší je napsat standardní konfigurační program, který to na základě developerem dodané konfigurace provede. Případný zájemce si sice bude muset pro kompilaci kromě tarbalu pořídit i tento program - to je však jednorázová akce.
• Použití tohoto konceptu vyřeší problém s aktualizací. Nebude nutné aktualizovat distribuční tarbally jen proto, že obsahují starý libtool nebo chybně vygenerované Makefile.in automakem. Aktualizace konfiguračního systému postačí.
• Nebude nutné řešit platformovou portabilitu pomocí různých hacků v ./configure. Na některých platformách se i zcela základní shell funkce jako např. echo chovají odlišně. To sice může být pro interní použití v ./configure ošetřeno a snad i je, ale vývojář používá bourne shell pro programování configure.ac a tak i on si musí dávat zvýšený pozor na portabilitu.
• Systém je POSIX only. Okna nejsou podporována. Projekty tak mají autoconf pro Unix a systém MSVC projekt souborů pro okna, což je zbytečná duplikace práce.
• Odstranění dlouhodobých omezení vyžaduje radikální řez, ne pouze novou verzi.
• Forward kompatibilita je špatná, zpětná neexistující. Já jsem musel nainstalovat: dvě verze libtoolu, 3 verze autoconfu, 3 verze automake...

Autoconf

• programuje se ve dvou programovacích jazycích: m4 a bourne shellu.
• nedostatečná, žádná? detekce chyb v configure.ac. Jazyky shell a m4 nevynikají nějakou zvlášť dobrou syntaktickou kontrolou.
• ./configure nehlásí chybné argumenty zadané na příkazové řádce. To má být údajně featura ne bug. SCons tohle dělá taky, ale tam se tomu dá snadno zabránit.
• občas chybná funkce v případě že jsou environment nastavení při ./configure a buildu odlišné.
• nerespektování nastavených proměnných během rekonfigurace. Pokud nastavím AUTOMAKE=automake19, proč autoconf vytrvale hledá automake-1.9? Že by dával cvičení na symlinky?
• Kešování výsledků testů není moc developer friendy. Proč neintegrovat podporu AC_CACHE_CHECK do AC_CHECK maker?
• Vygenerovaný ./configure je dost dlouhý. Například u PHP4 má přes 2 MB.

Automake

• možnosti přizpůsobení si buildu svým specifickým potřebám jsou minimální. Nutno přizpůsobit build automaku.
• vygenerované závislosti někdy nezafungují správně. t.j. provedou nekorektní build.
• pracuje per-adresář, nikoliv globálně. Závislosti napříč adresáři nefungují zcela.
• vygenerované Makefiles jsou příliš složité, pokud napíšete chybně Makefile.am a automake to nezjistí, těžko se následně hledá chyba.
• Makefile.am ze starších verzích v novějším automake nefungují.
• Systém mívá problémy s přegenerováním sebe sama po změně Makefile.am.

Zde bych raději skončil, článek má být o SCons a ne o GNU Autotools brain damage. GNU Autotools mám rád -pouze- jako uživatel (./configure;make install), nikoliv jako programátor.

SCons

Historie

Nástoj SCons začal svoji existestenci jako vítězný projekt Software Carpentry SC Build competition. Ačkoliv zvítězil, nezdál se investorům natolik zajímavý, aby jej finančně podpořili. Vývoj SCons to naštěstí nezastavilo a tak se dnes můžeme těšit z tohoto vynikajícího nástroje.

Návrh SConsu nebyl původní, šlo o vylepšení projektu Cons . Oba projekty si byly dost podobné. Nejpodstatnější rozdíl mezi oběma projekty byl použitý programovací jazyk. Cons byl založen na Perlu, zato SCons na Pythonu.

Základní Koncepty SCons

1. Globální pohled na projekt

Největší výhoda. Před začátkem kompilace jsou zpracovány konfigurační soubory ve všech adresářích a je vytvořen graf závislostí pro celý projekt. Nemůže se tudíž stát, že některé části zůstanou neaktualizované díky závislostem napříč adresáři. Použití této metody je zárukou, že build bude korektní.

2. Konfigurační soubory jsou programy

Snahy o programování v Makefile jsou známé. Nejvyspělejší verze utility Make - PMake a GNUMake rozšířili POSIX.2 Make standard alespoň o základní příkazy pro flow control. SConst jde však ještě dál. Koncept konfiguračních souborů jako vstupních dat pro utilitu make byl zrušen. Konfigurační soubory jsou plnohodnotné programy v programovacím jazyku Python. SCons exportuje do těchto programů své API, které tyto programy používají pro sestavení grafu závislostí projektu. Konfigurační programy mouhou pro jeho sestavení využívat všechny rysy jazyka Python včetně modulů.

3. Automatická analýza závislostí

Pokud SCons obsahuje podporu pro použitý programovací jazyk jsou zdrojové soubory automaticky analyzovány a nelezené závislosti přidány do projektu.

4. Použití MD5 signatur místo časových

SCons používá standardně MD5 signatury zdrojových souborů. Pokud je zdrojový soubor modifikován např. CVS checkoutem ale MD5 signatura zůstala nezměněná, není rekompilace nutná.

5. Automatické generování akce clean

SCons ví, co vznikne z kterých souborů po jejich kompilaci, linkování či instalaci. Může proto na požádání provést i obrácenou akci - clean, deinstalaci, atd.

6. Použití více prostředí

SCons umí v jednom projektu používat více prostředí. V rámci prostředí lze definovat odlišný kompilátor, jeho nastavení, promenné prostředí, atd. Pod Windows se to hodí, jelikož lze z bez problémů vyrábět na jeden zátah cygwin i native binárky.

7. Vše v jednom

SCons zcela nahrazuje utility GNU Autoconf, GNU Automake, GNU Libtool, GNU Make.Je to kompletní build systém a ne pouhý Makefile generátor.

8. Platformová nezávislost

SCons ke své činnosti nepotřebuje žádný externí program s výjímkou programů nutných k sestavení projektu. SCons postačí Python 1.5 či vyšší a pracuje bezproblémů ve všech prostředích podporovaných Pythonem.

9. Podpora pro testování prostředí

Před vlastní kompilací je možné provádět testy. Lze hledat knihovny, hlavičky, funkce, struktury a používat konfiguraci z programu pkgconfig. Při generování testovacích programů a jejich spouštění je automaticky použit aparát pro správu závislostí, čož zaručuje jejich kešování a konzistenci.

10. Snadná rozšiřitelnost

SCons bylo napsáno tak, aby se velmi snadno rozšiřovalo. Pro podporu nového jazyka, kompilátoru nebo prostředí obvykle stačí napsat zhruba jednu stránku Python kódu.

11. Příznivá licence

SCons je licencováno pod velmi příznivou licencí, známou jako MIT/X11, která zaručuje bezproblémové použití pro všechny typy projektů.

12. Podpora pro buildování z VCS

SCons umí získat zdrojové kódy z CVS, BitKeeper, RCS, SCSS, Perforce.

13. Vysoká flexibilita

Díky možnosti přímého použití Pythonu při generování grafu projektu, získáte o stupeň lepší flexibilitu než v případě použití klasických konfiguračních souborů. Nejste nikterak omezováni a konečně si můžete přizpůsobit build systém tak, jak vyhovuje vám.