Czy automake i autoconf to standardowy sposób kompilacji kodu?

Czasami kompiluję aplikacje ze źródła i albo używam:

./configure
make
sudo make install

Ale ostatnio natknąłem się na to, ./autogen.shktóra generuje konfigurację i tworzy skrypty dla mnie i wykonuje je.

Jakie istnieją inne metody usprawnienia kompilacji C / C ++ / C # (mono)? Make wydaje się trochę stary. Czy są tam jakieś nowe narzędzia? Biorąc pod uwagę wybór, którego powinienem użyć?

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 && makesprawdzał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 disti make distcheckprzygotowują ź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

W tym obszarze jest dwóch „dużych graczy”; Cmake i GNU Autotools.

• GNU Autotools to GNU sposób na robienie rzeczy i jest dość skoncentrowany na * nix. Jest to rodzaj systemu meta-kompilacji, który zapewnia zestaw narzędzi, które generują określoną konfigurację i tworzą pliki do tego, co próbujesz zrobić. Pomaga to wprowadzać więcej zmian w kodzie bez konieczności bezpośredniej manipulacji systemem kompilacji, a także pomaga innym budować kod w sposób, dla którego nie zaprojektowałeś - poniżej * nix.

• Cmake to wieloplatformowy sposób robienia rzeczy. Zespół Cmake tworzy oprogramowanie na wiele różnych sposobów, z GCC, Visual Studio, XCode, Windows, OSX, Solaris, BSD, GNU / Linux, cokolwiek. Jeśli w ogóle martwisz się o przenośność swojej bazy kodu, jest to odpowiedni sposób.

Jak już wspomniano, niektórzy ludzie lubią Sconsa. Jeśli znasz język Python, może to zapewnić większą spójność w środowisku pracy.

Ruby ma również swego rodzaju system meta-kompilacji o nazwie Rake, który sam w sobie jest całkiem fajny i bardzo przydatny dla tych, którzy już znają Ruby.

Scons jest jednym z możliwych zamienników, chociaż nie mam osobistego doświadczenia. Jest również zaimplementowany w Pythonie, co może stanowić problem, w zależności od środowiska kompilacji.

Jeśli używasz C # / Mono, możesz użyć msbuild (plików .sln / .csproj używanych przez MonoDevelop i Visual Studio) do zarządzania całym procesem kompilacji.

Następnie możesz albo zbudować z MonoDevelop, albo uruchomić xbuild polecenie w swoim ulubionym terminalu (działa najlepiej w Mono> = 2.6). Jest to niezwykle łatwe i nie wymaga prawie żadnej pracy z Twojej strony, ponieważ MonoDevelop obsłuży pliki msbuild za Ciebie, i nie będziesz musiał ich edytować, chyba że chcesz ulepszyć rzeczy poza tym, co interfejs użytkownika MonoDevelop może dla Ciebie zrobić.

Nie znam sposobu, w jaki ludzie zależni od msbuild obsługują instalacje dla swoich projektów, ale zawsze możesz o to zapytać. ;-)

Dla C # możesz użyć xbuild (i msbuild na Windows), który zbuduje projekt z plików projektu.