Autoconf i Automake zostały opracowane w celu rozwiązania ewolucyjnego problemu Uniksa.
Gdy Unix ewoluował w różnych kierunkach, programiści, którzy chcieli przenośnego kodu, zwykle pisali kod w ten sposób:
#if RUNNING_ON_BSD
Set things up in the BSD way
#if RUNNING_ON_SYSTEMV
Set things up in the SystemV way
#endif
Ponieważ Unix został podzielony na różne implementacje (BSD, SystemV, wiele rozwidleń dostawców, a później Linux i inne systemy uniksopodobne), stało się ważne dla programistów, którzy chcieli pisać przenośny kod, aby pisać kod, który nie zależał od konkretnej marki systemu operacyjnego , ale w przypadku funkcji udostępnianych przez system operacyjny. Jest to ważne, ponieważ wersja uniksowa wprowadziłaby nową funkcję, na przykład wywołanie systemowe „wyślij”, a później inne systemy operacyjne ją przyjęłyby. Zamiast spaghetti kodu, który sprawdzał marki i wersje, programiści zaczęli sprawdzać funkcje, więc kod stał się:
#if HAVE_SEND
Use Send here
#else
Use something else
#endif
Większość plików README do kompilacji kodu źródłowego z powrotem w latach 90-tych deweloperów, aby edytować plik config.h i komentować prawidłowe funkcje dostępne w systemie lub dostarczać standardowe pliki config.h dla każdej testowanej konfiguracji systemu operacyjnego.
Ten proces był zarówno uciążliwy, jak i podatny na błędy i tak właśnie powstał Autoconf. Powinieneś pomyśleć o Autoconf jako języku składającym się z poleceń powłoki ze specjalnymi makrami, które były w stanie zastąpić proces edycji przez człowieka config.h narzędziem, które sondowało system operacyjny pod kątem funkcjonalności.
Zazwyczaj zapisujesz swój kod sondujący w pliku config.ac, a następnie uruchamiasz komendę autoconf, która skompiluje ten plik do wykonywalnej komendy config, którą widziałeś.
Podczas uruchamiania ./configure && make
sprawdzałeś funkcje dostępne w systemie, a następnie budowałeś plik wykonywalny z wykrytą konfiguracją.
Kiedy projekty open source zaczęły korzystać z systemów kontroli kodu źródłowego, sensowne było sprawdzenie pliku config.ac, ale nie wyniku kompilacji (konfiguracji). Autogen.sh to tylko mały skrypt, który wywołuje kompilator autoconf z odpowiednimi dla ciebie argumentami polecenia.
-
Automake wyrósł także z istniejących praktyk w społeczności. Projekt GNU ustandaryzował regularny zestaw celów dla Makefiles:
make all
zbuduje projekt
make clean
usunie wszystkie skompilowane pliki z projektu
make install
zainstaluje oprogramowanie
- rzeczy takie jak
make dist
i make distcheck
przygotowują źródło do dystrybucji i sprawdzają, czy wynik był kompletnym pakietem kodu źródłowego
- i tak dalej...
Tworzenie zgodnych plików makefile stało się uciążliwe, ponieważ wiele płyt kotłowych było powtarzanych w kółko. Tak więc Automake był nowym kompilatorem, który zintegrował się z autoconf i przetworzył „źródłowy” plik Makefile (o nazwie Makefile.am) w pliki Makefile, które następnie można było przesłać do Autoconf.
Łańcuch narzędzi automake / autoconf faktycznie używa wielu innych narzędzi pomocniczych i są one uzupełniane przez inne komponenty do innych konkretnych zadań. Wraz ze wzrostem złożoności uruchamiania tych poleceń, narodziła się potrzeba gotowego do uruchomienia skryptu i stąd pochodzi autogen.sh.
O ile mi wiadomo, Gnome był projektem, który wprowadził użycie tego skryptu pomocniczego autogen.sh