Maciej Piechotka

Czyli dlaczego autotools są najgorsze ale lepszych nie ma.

Autotoolsy jakie są każdy widzi. Są niezbyt łatwe do nauczenia się, ciężkie, sprawdzają masę niepotrzebnych rzeczy (np. czy to nie jest egzotyczny system, który miał 1 użyszkodnika pięć lat temu ;) ). Jednak mają kilka, niezastąpionych cech:

• Reguła najmniejszego zaskoczenia. Jak zainstalować program na GNU/Linux? ./configure && make && sudo make install
• Wsparcie dla libtool lub podobych
• Wsparcie dla pkg-config (CMake posiada)

Reguła najmniejszego zaskoczenia

Tak jak jesteś zaskoczony, jak okienko się nie zamknie naciskając X u góry tak byłbyś zaskoczony przez całą masę innych niekonwencjonalnych, nawet jeśli logiczniejszych, działań. Użytkownik, szczgólnie 'nie do końca techniczny' jest przyzwyczjony do ./configure && make && sudo make install. Czy będzie chciało mu się zgadywać, że chodzi o python setup.py, scons czy cmake && make? Szczególnie, że jest to jasny, prosty i naturalny podział zadań. IMHO każdy z 'nowych' autotoolsów powinien mieć wsparcie dla tych komend (choćby jako proxy) - żeby jak najmniej zaskakiwać użytkownika.

Wsparcie dla libtool

W windowsie mieliśmy kiedyś coś, co się nazywało piekło DLL. Libtool być może nie jest najlepszym wyjściem, ale na razie jedynym, jakie mamy. Wiele alternatywnych systemów o tym zapomina (przynajmniej w dokumentacji).

Piekło DLL przypominam to sytłacja w której program A wymaga libfoo.dll w wersji 1.1.0 a program B libfoo.dll w wersji 2.0.0. Ponieważ ABI się zmieniło pomiędzy 1.1.0 a 2.0.0 a nie ma metadanych w bibliotece o wersji to nie ma żadnej szansy na dowiedzenie się, dlaczego po zainstalowaniu B program A przestał działać. W Gentoo revdep-rebuild nie ma żadnych szans na działanie - po prostu brak jest tych informacji.

Pozbycie się metadanych o wersji w bibliotece wspieranych automatycznie przez system to krok wstecz.

Wsparcie dla pkg-config

Użytkownik może mieć zainstalowaną bibliotekę w setce różnych miejsc. Może to być /usr/lib, ale nic nie stoi na przeszkodzie żeby to było /usr/local/lib. Niektóre dystrybucje mogą po prostu umieścić ją w /lib. Cała masa nieszczęśników może mieć ją w c:/Program Files/<nazwa biblioteki>/lib. Jedynym sposobem, żeby wydobyć informacje o położeniu jest program zaistalowany na maszynie, gdzie jest ten program. Kiedyś dość popularne były programy typu <nazwa biblioteki>-config ale obecnie standardem stał się pkg-config.

Jest to prosta i uniwersalna metoda sprawdzenia:

• Czy biblioteka jest zainstalowana
• W jakiej wersji
• Czego potrzebuje (tzn. z czym trzeba się zlinkować)
• Gdzie są pliki nagłówkowe

Wszystko podane w formacie, który można dać wprost do kompilatora/linkera.

Jest to prosty sposób na poinformowanie Potrzebujesz biblioteki libxyz w wersji developerskiej.