Po co używać narzędzi do budowania, takich jak Autotools, skoro możemy po prostu pisać własne pliki Makefile?

Po pierwsze, Autotools nie są nieprzezroczystym systemem budowania, ale luźno sprzężonym łańcuchem narzędzi, jak już zauważył tinkertim. Dodam tylko kilka przemyśleń na temat Autoconf i Automake:

Autoconf jest systemem konfiguracyjnym, który tworzy skrypt configure na podstawie sprawdzeń funkcji, które mają działać na wszystkich rodzajach platform. W ciągu 15 lat istnienia makro bazy danych M4 znalazło się wiele wiedzy systemowej. Z jednej strony, myślę, że to ostatnie jest głównym powodem, dla którego Autotools nie został jeszcze zastąpiony przez coś innego. Z drugiej strony Autoconf był o wiele ważniejszy, gdy Platformy docelowe były bardziej heterogeniczne i linuksowe, AIX, HP-UX, SunOS,... i obsługiwała wiele różnych architektur procesorów. Naprawdę nie widzę sensu, jeśli chcesz tylko wspierać najnowsze dystrybucje Linuksa i procesory zgodne z Intelem.

Automake jest abstrakcją warstwa dla GNU Make i działa jako generator Makefile z prostszych szablonów. Wiele projektów w końcu pozbyło się abstrakcji Automake i powróciło do ręcznego pisania plików Makefile, ponieważ stracisz kontrolę nad plikami Makefile i możesz nie potrzebować wszystkich celów kompilacji, które zaciemniają Twój plik Makefile.

Teraz do Alternatywy (i zdecydowanie sugeruję alternatywę dla Autotools w oparciu o twoje wymagania):

CMake's najznakomitsze osiągnięcie polega na zastąpieniu AutoTools w KDE. Jest to prawdopodobnie najbliższy, jaki możesz uzyskać, jeśli chcesz mieć funkcję podobną do Autoconf bez idiosynkrazji m4. Przynosi obsługę systemu Windows do tabeli i okazał się mieć zastosowanie w dużych projektach. Mój problem z CMake polega na tym, że nadal jest generatorem plików Makefile (przynajmniej na Linuksie) ze wszystkimi jego immanentnymi problemami (np. debugowanie plików Makefile, sygnatury znaczników czasu, domyślna kolejność zależności).

SCons jest zamiennikiem marki napisane w Pythonie. Używa skryptów Pythona jako plików sterujących budową pozwalających na bardzo wyrafinowane techniki. Niestety jego system konfiguracji nie dorównuje Autoconf. SCons jest często używany do wewnętrznego rozwoju, gdy dostosowanie do konkretnych wymagań jest ważniejsze niż przestrzeganie konwencji.

Jeśli naprawdę chcesz trzymać się Autotools, zdecydowanie polecam przeczytać rekurencyjny uczynić szkodliwym i napisać własny plik GNU Makefile skonfigurowany przez Autoconf.

Odpowiedzi podane tutaj są dobre, ale zdecydowanie polecam nie korzystać z porad, aby napisać własny plik makefile, jeśli masz coś przypominającego standardowy projekt C / C++. Potrzebujemy autotools zamiast ręcznie pisanych plików Makefile, ponieważ zgodny ze standardami plik Makefile generowany przez automake oferuje wiele przydatnych celów pod dobrze znanymi nazwami, a ręczne dostarczanie tych celów jest żmudne i podatne na błędy.

Po pierwsze, pisanie pliku Makefile ręcznie wydaje się świetnym pomysłem na po pierwsze, ale większość ludzi nie będzie zawracać sobie głowy, aby napisać więcej niż zasady dla wszystkich, zainstalować i może wyczyścić. automake generuje dist, distcheck, clean, distclean, uninstall i wszystkie te małe helpery. Te dodatkowe cele są wielkim dobrodziejstwem dla sysadmin, który ostatecznie zainstaluje Twoje oprogramowanie.

Po drugie, zapewnienie wszystkich tych celów w przenośny i elastyczny sposób jest dość podatne na błędy. Zrobiłem ostatnio wiele cross-kompilacji do celów Windows, a autotools wykonali tylko świetnie. W przeciwieństwie do większości ręcznie pisanych plików, które były w większości wrzodem na tyłku do kompilacji. Pamiętaj, że to jest możliwe, aby stworzyć dobry plik Makefile ręcznie. Ale nie przeceniaj siebie, wymaga to dużego doświadczenia i wiedzy na temat wielu różnych systemów, a automake tworzy świetne pliki Makefile dla Ciebie od razu po wyjęciu z pudełka.

Edit: I nie daj się skusić na użycie "alternatyw" . CMake i przyjaciele to dla deployera horror, bo nie są interfejs-kompatybilny z konfiguracją i znajomymi. Każdy w połowie Kompetentny sysadmin lub programista może zrobić wielkie rzeczy, takie jak kompilacja krzyżowa lub proste rzeczy, takie jak ustawienie prefiksu z głowy lub z prostym -- pomoc z konfigurować skrypt. Ale jesteś przeklęty, że spędzasz godzinę lub trzy, kiedy musisz robić takie rzeczy z BJam. Nie zrozumcie mnie źle, BJam to chyba świetny system pod maską, ale to wrzód na dupie w używaniu, bo nie ma prawie żadnych projektów z niego korzystających i bardzo mało i niekompletna dokumentacja. autoconf i automake mają tutaj ogromną przewagę pod względem ustalonej wiedzy.

Więc, mimo że jestem trochę spóźniony z tą radą na to pytanie: zrób sobie przysługę i użyj autotools i automake. Składnia może być trochę dziwna, ale wykonują o wiele lepszą pracę niż 99% deweloperów robi to samodzielnie.

W przypadku małych projektów lub nawet dużych projektów, które działają tylko na jednej platformie, ręcznie pisane pliki Makefile są dobrą drogą.

Gdzie autotools naprawdę świeci, gdy kompilujesz dla różnych platform, które wymagają różnych opcji. Autotools jest często mózgiem typowym

./ configure

Make

Make install

Kroki kompilacji i instalacji bibliotek i aplikacji Linuksowych.

To powiedziawszy, uważam autotools za ból i szukałem lepszego systemu. Ostatnio używam bjam, ale to też ma swoje wady. Powodzenia w znalezieniu tego, co Ci odpowiada.

Autotools są potrzebne, ponieważ pliki Makefile nie mają gwarancji, że będą działać tak samo na różnych platformach. Jeśli ręcznie piszesz plik Makefile i działa on na twoim komputerze, istnieje duża szansa, że nie będzie na moim.

Czy wiesz, jakiego Uniksa będą używać Twoi użytkownicy? A może nawet jaka dystrybucja Linuksa? Wiesz, gdzie chcą zainstalować oprogramowanie? Czy wiesz, jakie mają narzędzia, na jakiej architekturze chcą kompilować, ile mają procesorów, ile pamięci RAM i dysku mogą być dla nich dostępne?

Świat *nix to wieloplatformowy krajobraz, a twoje narzędzia do budowania i instalowania muszą sobie z tym poradzić.

Pamiętaj, że narzędzia auto * pochodzą z wcześniejszej epoki i jest wiele ważne skargi na nich, ale kilka projektów, aby zastąpić je bardziej nowoczesne alternatywy mają problem z rozwijaniem dużo rozmachu.

Wiele rzeczy jest takich w świecie * nix.

Autotools to katastrofa.

Wygenerowany skrypt ./configure sprawdza funkcje, które nie były obecne w żadnym systemie uniksowym przez ostatnie 20 lat. Aby to zrobić, spędza ogromną ilość czasu.

Bieganie ./configure trwa wieki. Chociaż nowoczesne procesory serwerowe mogą mieć nawet dziesiątki rdzeni i może być ich kilka na serwer, ./configure jest jednowątkowy. Zostało nam Jeszcze tyle lat prawa Moore ' a, że liczba rdzeni procesora wzrośnie w funkcji czas. Tak więc czas ./configure będzie w przybliżeniu stały, podczas gdy równoległe czasy budowania zmniejszają się o współczynnik 2 co 2 lata dzięki prawu Moore ' a. A właściwie powiedziałbym, że czas ./configure może nawet wzrosnąć ze względu na rosnącą złożoność oprogramowania wykorzystującego ulepszony sprzęt.

Samo dodanie tylko jednego pliku do projektu wymaga uruchomienia automake, autoconf i ./configure, co zajmie wieki, a wtedy zapewne przekonasz się, że skoro niektóre ważne pliki mają zmiana, wszystko zostanie skompilowane. Dodaj tylko jeden plik i make -j${CPUCOUNT} przekompiluje wszystko.

I O make -j${CPUCOUNT}. Generowany system budowania jest rekurencyjny. Recursive make przez długi czas był uważany za szkodliwy .

Po zainstalowaniu skompilowanego Oprogramowania okaże się, że nie działa. (Chcesz dowodu? Klon protobuf repozytorium z Github, sprawdź commit 9f80df026933901883da1d556b38292e14836612, zainstaluj go na systemie Debian lub Ubuntu, i hej presto: protoc: error while loading shared libraries: libprotoc.so.15: cannot open shared object file: No such file or directory -- ponieważ jest w /usr/local/lib, a nie /usr/lib; obejście polega na wykonaniu export LD_RUN_PATH=/usr/local/lib przed wpisaniem make).

Teoria jest taka, że używając autotools, można stworzyć pakiet oprogramowania, który może być skompilowany na Linuksie, FreeBSD, NetBSD, OpenBSD, DragonflyBSD i innych systemach operacyjnych. Fakt? Każdy Nie-Linuksowy system do budowania pakietów ze źródła ma w swoim repozytorium liczne łatki do obejścia błędów autotools. Wystarczy spojrzeć na np. FreeBSD /usr/ports: jest pełen łatek. Więc, równie łatwo byłoby utworzyć małą łatkę dla systemu budowania nie-autotools na podstawie projektu, niż utworzyć małą łatkę dla systemu budowania autotools na podstawie projektu. A może nawet łatwiej, ponieważ standard make jest znacznie łatwiejszy w użyciu niż autotools.

Faktem jest, że jeśli stworzysz swój własny system budowania oparty na standardowym make (I uczynisz go inkluzywnym, a nie rekurencyjnym, zgodnie z zaleceniami artykułu "Recursive make considered harmful"), rzeczy działają w o wiele lepszy sposób. Ponadto, twój czas kompilacji spada o rząd wielkości, być może nawet dwa rzędy wielkości, jeśli twój projekt jest bardzo mały projekt 10-100 plików języka C i masz dziesiątki rdzeni na procesor i wiele procesorów. Znacznie łatwiej jest również połączyć niestandardowe narzędzia do automatycznego generowania kodu z niestandardowym systemem budowania opartym na standardowym make, zamiast radzić sobie z bałaganem autotools. Standardowym make, możesz przynajmniej wpisać polecenie powłoki do Makefile.

Aby odpowiedzieć na twoje pytanie: po co używać autotools? Odpowiedź: nie ma ku temu powodu. Autotools jest przestarzały od czasu, gdy komercyjny Uniks stał się przestarzały. Pojawienie się procesorów wielordzeniowych sprawiło, że autotools stał się jeszcze bardziej przestarzały. Dlaczego programiści jeszcze tego nie zrozumieli, to zagadka. Chętnie użyję standard make na moich systemach budowania, dziękuję. Tak, potrzeba trochę pracy, aby wygenerować pliki zależności dla włączenia nagłówka języka C, ale ilość praca jest zapisywana przez brak konieczności walki z autotoolami.

Nie czuję się ekspertem, aby odpowiedzieć na to pytanie, ale nadal dać trochę analogii z moim doświadczeniem.

Ponieważ do pewnego stopnia jest to podobne do tego, dlaczego powinniśmy pisać osadzone kody w języku C (High Level language), a nie pisać w języku asemblera. Oba rozwiązują ten sam cel, ale ten ostatni jest bardziej długi, żmudny ,czasochłonny i bardziej podatny na błędy (chyba że dobrze znasz Isa procesora) . Podobnie jest w przypadku narzędzia Automake i pisania własnego pliku makefile. Pisanie Makefile.am oraz configure.ac jest to dość proste niż pisanie indywidualnego pliku Makefile projektu.