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


22

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ć?


nie ma to jak „kod”. Na przykład, jeśli otrzymasz kod Java, prawdopodobnie zbudujesz go za pomocą maven lub ant, jeśli dostaniesz Python, dobrym wyborem są narzędzia konfiguracyjne. Nie ma standardowych sposobów na kompilację czegokolwiek. Może powinieneś przeformułować pytanie.
diega

Słuszna uwaga. Właściwie koduję w C # z mono, ale moje pytanie dotyczy również C / C ++.
Louis Salin,

Mała uwaga: autogen.sh nie wykonuje make for you, wystarczy skonfigurować.
Sandy,

@Sandy autogen.shto w większości niestandardowe skrypty, które zwykle wywołują, autoreconfale mogą również wywoływać, ./configurea nawet make. Nie sądzę, że jego zachowanie jest w jakikolwiek sposób ustandaryzowane; głównym celem jest posiadanie możliwego do wykonania pliku w ramach projektu, który ludzie mogą uruchomić (zamiast wiedzieć, że muszą wyczarować autoreconf)
umläute,

Odpowiedzi:


42

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


Drobna nitka: standardy GNU nakazują wysyłanie wygenerowanych plików w plikach tar, aby zmniejszyć zależności kompilacji do minimum powszechnie dostępnych narzędzi. Jeśli otrzymasz surowe źródło (na przykład z systemu kontroli wersji), wygenerowanych plików nie będzie tam.
vonbrand,

14

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.


6

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.


2
Przenośność nie stanowi problemu, ponieważ Python jest teraz praktycznie wszędzie. Jak dotąd główną skargą na temat SCons jest to, że jest on nie do przyjęcia powoli. Jest kilka drobiazgów, które poświęcą dokładność budowania na rzecz prędkości, ale nie jestem pewien, czy nadal jest na równi z Make.
Alex B,

3

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ć. ;-)


Tak, wiem o Xbuild, ale staram się oderwać od IDE, które chcą tylko trzymać mnie za rękę. Plus, Mono jest kompilowany za pomocą Mono i używa autoconf, więc chciałem dowiedzieć się nieco więcej. Dzięki!
Louis Salin,

1
Co ciekawe, wiele projektów Mono próbuje migrować do msbuild teraz, gdy xbuild działa tak dobrze. Ułatwia to obsługę systemów Windows / Mac. Mono ma tak dużo kodu C, że nie jestem pewien, jak praktyczne byłoby przejście na Xbuild. Ale autoconf działa świetnie, więc rób wszystko, co dla ciebie działa. :-)
Sandy

0

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

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.