Názory k článku GNU - pomoc při tvorbě programů: Automake

> za vás autoconf udělá opravdu spoustu práce, neboť vygenerované soubory Makefile.in mají v obou případech přes 400 řádek a obsahují všechny výše zmiňované standardní cíle. Doufám, že se vám to začíná líbit...

Ne, nelíbí se mi to ani trochu, je to děs a hrůza. Ručně psaný makefile je mnohem lépe udržovatelný. Také se mi vůbec nelíbí autoconf. Nejlepší je distribuovat separátní makefile pro každou platformu. Ty jsou pak malé, přehledné a udržovatelné, vše je na svém místě, dá se v tom vyznat a případně opravit co je třeba.

Jakýsi bloated configure skript je neprůhledný, často funguje nespolehlivě (havaruje s podivnou diagnostikou, nebo skončí úspěšně ale aplikace pak stejně nejde přeložit, protože autor configure.in na něco zapoměl). Část přepínačů není dokumentována. Navíc se to snaží dělat fůru věcí hrozně "chytře", takže třeba nejde změnit pořadí detekce knihoven, atd.

Změna flagu pro linker z -ldb na -ldb3, což by byla triviální změna jednoho řádku v Makefile, pak znamená půlden strávený studováním a editací configure skriptu..

Základní myšlenka je to dobrá, ale muselo by to VŽDY fungovat. Když to nefunguje, je nejlepší řešení to NEJJEDNODUŠŠÍ, a tím asi nebudou 100kB+ shellové skripty. Zničit krtka!

Ručně psaný makefile (nebo ještě hůř sada různých Makefile pro různé platformy) není vůbec udržovatelné. Sám jsem si to měl možnost zkusit - zvlášť pokud uživatelé nejsou zběhlí v UNIXu, ale potřebují se jen umýt a jít - ehm, tedy spustit ./configure a make. A do configure lze (na rozdíl od makefile) dávat run-time testy hostitelského systému (u výpočetních programů jsem například potřeboval nejvhodnější optimalizační přepínače pro g77 nebo detekci na chybnou implementaci erf() v jedné starší verzi libm). A to nemluvím o tom, že uživatelé s oblibou kompilují program na takových kombinacích operačního systému a knihoven, o kterých se autorovi programu ani nezdálo. Podle mého názoru je Makefile.in zhruba stejně dlouhé jako by bylo Makefile, a délka configure.in naprosto vyváží případných několik mutací Makefile pro různé OS. Autoconf rozhodně nevyrábí bloatware. Automake nepoužívám, ale myslím, že to nebude zase tak strašné. Co je komu po tom, že výsledný Makefile je 4x tak dlouhý. Na výsledném zkompilovaném programu se to nijak neprojeví, a pomůže to při údržbě balíku.

-Yenya

> jen umýt a jít - ehm, tedy spustit ./configure a make.

Ano, v tom vidím i smysl autoconfu: aby instalace zdrojového balíku byla no-brainer na co nejvíce platformách. Většinou to opravdu funguje, ale často to také vypadá tak, že půlmegový configure skript nejprve minutu chrochtá a zkouší jestli opravdu funguje ona strašně exotická funkce strcpy, pak vygeneruje deset makefile a deset headerů, které bez dodatečné editace stejně produkují nefunkční aplikaci, takže práci to naopak přidává. Fakt je že možná jde o dobrý nástroj, který je občas špatně používaný, ale můj osobní názor je, že by se mělo mnohem více pozornosti věnovat sjednocování API, než workaroundům typu autoconf (vždyť nic jiného to stejně není). Nyní bohužel není vůbec výjimkou, že samotný configure skript je delší, než zdrojáky zbytku aplikace, a poměr dob běhu configure a samotného překladu je podobný.

> A do configure lze (na rozdíl od makefile) dávat run-time testy hostitelského systému

S tím si dovoluji uctivě nesouhlasit. Jde to hned několika způsoby, od prostého použití backquote při nastavování proměnné, až po hrubou sílu: vygenerování dalšího makefile, a rekurzivního spuštění make na něj. Souhlasím ale, že pokud balík potřebuje *opravdu* rozsáhlé runtime testy, je použití speciálního nástroje typu autoconf asi lepší řešení.

Abych rekl pravdu, po nejakem case stravenem u Autoconfu jsem zastaval velmi podobny nazor. Ale po nekolika dalsich pokusech jsem zjistil, ze slo vetsinou o to, ze jsem delal neco spatne ja. Po dalsim studiu jsem nakonec dosel na to, ze to je opravdu pomerne uzitecny software. Jen ho umet ovladat. Samozrejme ma svoje chyby a mouchy, ale nikdo Vas nenuti ho pouzivat. Stejne jako se musite starat o sadu souboru Makefile se tady musite starat o jinou sady souboru. Jako muzete udelat chyby v souborech Makefile muzete je udelat i tady. Vyhody bych shrnul asi do trech zakladnich veci:

- pisete toho mene (ve vetsine pripadu)
- pravdepodobne to bude fungovat i na systemech ktere jste vubec neuvazoval
- minimalne nektere testy jsou opravdu uzitecne ve zdrojovem kodu (sizeof(type), volani spravne funkce, ...)

Nicmene neni to jedina cesta a moznosti je jako vzdy v Unixu/Linuxu spoustu.