Eric S. Raymond - az autotools-nak meg kell halnia

+1. A `cmake` is tud erdekes dolgokat produkalni. Futtatnam, kiirja hogy hianyzik neki a libx-dev. Oke, felteszem, fut tovabb. Hianyzik neki a liby-dev. Oke, felteszem, fut tovabb. Hianyzik neki a libz-dev. Oke, felteszem, nem fut tovabb, random teljes osszeomlas. Es akkor par ora szopas utan rajovok hogy neha nem art torolni a "CMakeCache.txt"-t. Ugyhogy par ilyen elmeny utan megszoktam hogy a `cmake` futtatasa elott biztos-ami-biztos torlom ezeket a jarulekos file-okat. Azaz, hat, mondjuk ugy hogy nem sokkal lettunk elorebb egy klasszik ./configure-hoz kepest :/ 

Ezzel nyilvan nem azt mondom hogy a ./configure az jo, de a tobbi sem jobb. Vagyis, mashogy szar. Hat, ez van. 

Bizonyos mértékig igaz, amit mondasz, mert az egész autotools, libtool, pkgconfig miegymás valójában egy csodát akar tenni.

Van kismillió disztribúció (linux és más unix vagy unix-származék), mindegyik máshová teszi a libeket, máshová a header-öket stb. Persze van néhány konvencionális hely (egy rendszeren belül is egynél több), amit a nagy többség betart, kivéve a nagyon ezós disztrókat. A libek között nincs szigorú kompatibilitás (megintcsak konveniók vannak a számozásra, amiket néha lazán tartanak be). Vannak aztán a sokféle C, C++ fordítók, linkerek, a különféle paraméterezéseikkel, ami még azonos családon belül verziók között sem feltétlen teljesen kompatibilis. Az autotools nem kevesebbre vállalkozik, hogy mindezen különbségek ellenére valami "varázslattal" megoldja, hogy a fordítás az adott rendszerre működjön.

Ez a varázslat nem mindig fog sikerülni, és ennek az oka sokszor nem maga az autotools (vagy legalábbis nem közvetlenül).

Mi történik valójában a háttérben? Az egyes felrakott libek hozzák magukkal a saját m4 makróikat. (Amik szintén nem alkotnak egy szigorúan jól definiált, előre-hátra kompatibilis interfész contract-ot, inkább csak szokások alapján szerveződik). És ezekből a millió forrásból származó makrókból próbál valahogy scripteket, meg makefile-okat generálni. Elég egy-két elcseszett csomag, ami beleront az m4 definíciókba és már törik egy másik csomag buildje.

Valójában az autotools az egyik szőnyeg alól egy másik alá söpri be problémát. És ezzel nyilván az alternatívák sem tudnak sokkal többet kezdeni.

Akkor mi a baj vele? Az, hogy iszonyúan bonyolultra lett csinálva, túl sok közbenső generálási lépéssel. Hogy a leg-archaikusabb sh interpreterre generálja a scripteket (mert valami ortodox unix platformon alapból csak az lesz fenn), ami emiatt workaround-ok tömkelegét tartalmazza. Az, hogy nem igazán tudod levalidálni, hogy jó-e amit csinálsz benne, csak a saját rendszereden látod, hogy megy-e a fordítás. Nem látod, hogy egy másik rendszeren egy másik lib fordítását nem törted-e el valami makróval (adott disztrók source csomagjaiban meglepően sokszor találni build-patcheket). Az hogyha hiba van, nem tudod könnyen visszavezetni, hogy honnan jött az input a hibásan generálódó részhez. Egy C, C++ fejlesztő egyszerűen nem ezzel akar mélységében foglalkozni, megcsinálja legjobb tudása szerint éppen működőre, aztán simán lehet, hogy a disztró készítőknek utána kell patchelniük.

Ennél azért lehetne ma már jóval többet és jobbat csinálni, ami interface contract-okat sokkal jobban tudja validálni. Deklaratívabb, gráf-jellegű adatbázisban tudja követni a függőségeket, valamilyen modell-ellenőrzéssel az összes lehetséges kombinációt (amikor a configure-ban opcionális függőségek vannak) végig tudja pörgetni, hogy kiderüljön, hogy van-e problémás eset. Akár nem saját rendszerednek megfelelő adatbázissal is le tudhatná ellenőrizni, hogy az ottani felállásnál előreláthatólag lesz-e baj belőle.

Nyilván bilibe lóg az ember keze, mert 100000 autotools-os projektet nem lehet csak úgy átállítani másra.