Sestavování aplikací
Od raných dob počítačů, od dob, kdy vznikly překladače, čelí programátoři stejnému problému. Mají kopec zdrojových souborů a chtějí z nich udělat spustitelný program. Od zrodu UNIXu se to snaží řešit program make a, později, i některé další. Přesto však situace zdaleka není nejlepší.
Proberme si, jak vypadá aktuální stav a jak by se to možná dalo vyřešit.
make
Obecně uznávaný, používaný na spoustu menších věcí. Taktéž se používá jako jádro mnoha dalších systémů. Píše se o něm v každé knize pro programátory v UNIXu. Snad neexistuje nikdo, kdo to myslí s programováním vážně a alespoň o něm neslyšel.
Na druhou stranu by se slušelo zmínit pár nešikovností. Například že rozlišuje mezi tabulátory a mezerami. Tento rozdíl není v editoru vidět a vede k problémům a zmateným uživatelům.
Trochu zásadnější je problém s proměnnými. Zatímco většina syntaxe se tváří, že nezáleží na pořadí, u proměnných tomu tak v některých případech není. Existují dva druhy přiřazení. Přiřazení „okamžité“, kdy se výraz vyhodnotí a uloží výsledek, a přiřazení „zpožděné“, kdy se uloží výraz a vyhodnotí se pokaždé, když někdo požaduje hodnotu proměnné. U obou záleží na pořadí, pokud se do jedné proměnné přiřadí vícekrát, u prvního dokonce i vzájemné pořadí přiřazení do různých proměnných. Trochu moc různých chování na jeden jazyk, ne?
Překlad programu uloženého ve více adresářích je nevyřešený. Sice lze pouštět rekurzivně v podadresářích, je tu však problém s propagací proměnných. Trochu smysluplně se to dá vyřešit vkládáním Makefilů z podadresářů, pak ale funguje jen překlad z kořene a dá to docela práci napsat, aby to fungovalo.
Automatické řešení závislostí je také problematické. Interně řešené není, je tedy třeba generovat malé Makefily, obsahující pouze závislosti, a ty vkládat. Potom, když je 500 zdrojových souborů, tak nebohý make vkládá 500 závislostních souborků a nebo programátor strávil několik bezesných nocí laděním jejich spojování ve správnou chvíli.
Mezi další problematické oblasti se řadí například překlad do odděleného adresáře, autodetekce prostředí či poněkud obtížné ladění obecných pravidel.
Generátory makefilů
Tato myšlenka vychází z předpokladu, že když nedokáže člověk napsat Makefile, který by fungoval, tak tu nefunkčnost dokáže nějaký generátor schovat do hromady balastu. Jednoduše, když nejde napsat obecné pravidlo pro všechny soubory ve všech adresářích, proč jich nenagenerovat všech 500?
Myšlenka jistě hezká, ale snad jediný rozšířený generátor je automake, doprovázený přáteli autoconf a autoheader. Jejich syntaxe je poněkud šílená (např. problémy s tím, co se má quotovat 4* a co 5*). Již nějakou dobu se snažím potkat člověka, který by o sobě dobrovolně prohlásil, že těm jazykům rozumí. Nepodařilo se mi to ani na IRC kanále KDE, kde bylo 200 lidí. V době, kdy KDE tyto programy ještě používalo. Inu, třeba se mi mé přání někdy splní a potkám se s autorem. Navíc to nageneruje obvykle několik tisíc řádků skriptů. Zkuste si to ladit.
Přitom to původní problémy neřeší, jen schovává.
Možná by stálo za to zmínit ještě cmake a qmake, ale oba jsou jazykově specifičtí a problémy make stejně neřeší. Alespoň netrpí tolika problémy, jako jejich motorističtí bratříčci (auto*).
Scons
Docela hezká věcička napsaná v pythonu. A nejen ona, ale i kontrolní skripty. Pomocí několika poskytnutých funkcí lze systému vysvětlit, co že se po něm vlastně chce, jaké to má závislosti, kam to uložit a podobně. Při tom je možné používat vše, co python poskytuje.
Samozřejmě obsahuje i funkce na způsob „chci Cčkový program z těchto zdrojových souborů“, včetně řešení závislostí.
Celkově inovativní, jednoduchý na pochopení a čistý. Popis kompilace nevypadá jako když vrabec tancoval po klávesnici a je čitelný i pro většinu lidí, kteří Scons neznají.
Nevím, jak si stojí ve složitějších případech. Nová pravidla a funkce samozřejmě dopisovat jdou, nevypadalo to ani moc složitě, tak by tam žádný chyták být nemusel, jen jsem ho u ničeho většího nepotkal.
Avšak, obdobně jako u pythonu samotného, za čistotu jazyka se platí tvrdou měnou rychlosti. Když u většího projektu nic nezměníte a znovu pustíte make, tak on téměř okamžitě odpoví, že nemá nic na práci. Scons si to napřed pořádně rozmyslí. To může na první pohled vypadat neškodně, vývoj to ale poněkud znepříjemní. A naštvaný programátor píše mnohem více chyb.
Jazykově specifická řešení
Mnoho jazyků má nějaký svůj vlastní systém. Takovým příkladem může být např. ant, který rádi používají vývojáři v javě. Pokud pominu to, že psát skripty v XML by se mi osobně nechtělo (asi je to osobní preference, lidé kolem javy ho snáší celkem dobře), je zde ten problém vázanosti na daný jazyk. Pro libovolný jiný je to buď zcela nepoužitelné nebo alespoň značně nepohodlné. A nyní přijde na scénu projekt kombinovaný z několika jazyků, kousky jsou generované programy speciálně k tomu přeloženými v průběhu kompilace a podobně.
Tedy toto nelze použít jako univerzální řešení, v některých jednoduchých případech to použít jde.
Řešení vázaná na konkrétní IDE
Kromě vlastního navázání na ono IDE je zde obvykle zásadní problém. Neflexibilita. Jsou věci, které se prostě v GUI naklikat nedají, protože nikoho nikdy nenapadlo, že by se taková věc mohla někomu hodit. Většina z nich nezvládá už triviální požadavek, že některý soubor je generovaný skriptem.
Je to dobré pro začínajícího programátora, když se nechce zabývat tím, jak se z textu stane program. Ale na něco pořádného, kde navíc každý programátor chce používat jiné IDE (jestli vůbec nějaké chce), je to špatná volba.
Nové řešení - remake
Zatím to vypadá jen jako snůška stížností, že je všechno špatně. Proto bych rád nabídl něco, co možná časem bude řešení. Je tím projekt remake, ke kterému mě navedl a se kterým mi pomáhá Martin Mareš. Zatím je ve spíše ve stavu návrhu, než funkční implementace, ale protože mě bude škola tlačit k jeho dokončení, možná i někdy bude existovat.
Popis kompilace se bude skládat z kompilačních tříd a popisu objektů. Každá třída popisuje nějaký způsob kompilace, řekněme kompilaci objektového souboru z některého Cčkového zdrojáku. V ní se popíše jednak samotná kompilace, jednak jak se po kompilaci uklidí, jak se zjistí závislosti, případně kterékoliv jiné akce.
Popis objektů je jen použití těchto tříd. Řekne se, že daný objekt nebo objekty (soubor) se použije na vstupu dané třídy, výsledek se vezme, použije do jiné třídy a celé že je cílený výsledek.
Samozřejmě půjdou dělat třídy s libovolným množstvím vstupů, více druhy vstupů, s libovolným počtem výstupů a podobně.
Při spuštění lze vyžádat buď operace na daném seznamu objektů (např. pokud je zájem pouze o jeden z množiny programů) nebo seznam akcí (výchozí je provést kompilaci, ale lze požadovat například uklizení).
Další zajímavou vlastností je systém cache. Zatímco make a mnoho dalších nástrojů určuje, zda je potřeba přegenerovat nějaký soubor, podle toho, jestli výsledek je novější než zdroj, remake dle toho, jestli se změnil od minulé kompilace čas na zdroji. To lze použít na akce typu „uploadni na server“, které nemají žádný výstup, ale je třeba je provést, když se soubor změní.
Cache lze použít i k uchovávání hodnot proměnných. Pokud tedy uživatel některou hodnotu nastaví na příkazové řádce a uvnitř skriptu se nemění, pak se takto nastavená hodnota zapamatuje i pro příští spuštění. Stejně tak, autodetekované hodnoty se nadetekují jen jednou a příště se testy již spouštět nebudou.
Další zajímavou vlastností, která se mi doufám, povede implementovat, je vkládání perlu. Toto bude k dispozici proto, že jazyk remake nebude příliš rozsáhlý, většinou člověk potřebuje jen velmi jednoduché operace, ale občas se hodí nějaká naprogramovaná akce, regulární výraz, načtení souboru a podobně.
Bohužel, i pokud se povede celou tuto věc napsat, bude ji čekat ještě značný oříšek. Totiž rozšířit se. Make sice není nejlepší, ale má za sebou značný kus historie. Kdyby neměl, scons by již teď musel mít pozici s ním minimálně srovnatelnou.
Alespoň tedy nakonec jedna otázka. Ví někdo z váš o něčem plnohodnotně použitelném (pro libovolný jazyk), nebo budeme všichni odkázaní po další rok na make?
Diskuze