Jakie są różnice między Autotools, Cmake i Scons?


259

Jakie są różnice między Autotools, Cmake i Scons?


Ten temat jest już omawiany na wiki Scons . Proponuję odwiedzić następujące linki: 1. scons.org/wiki/SconsVsOtherBuildTools Czy odwiedziłeś bardzo podobny wątek dyskusyjny na forum Ubuntu ?
bhadra

Możesz sprawdzić ten pdf www-alt.gsi.de/documents/DOC-2007-Sep-17-1.pdf ; ma zalety i wady, a także pewne szczegóły dotyczące każdego narzędzia.
Adam,

Odpowiedzi:


190

W rzeczywistości „jedyną prawdziwą„ łaską oszczędzającą ”Autotools jest to, że w dużej mierze wykorzystują to wszystkie projekty GNU.

Problemy z narzędziami automatycznymi:

  • Prawdziwie składnia makr ARCANE m4 w połączeniu z pełnym, skręconym skryptem powłoki do testów pod kątem „kompatybilności” itp.
  • Jeśli nie zwracając uwagi, to będzie bałagan możliwości cross-kompilacji (Należy wyraźnie zaznaczyć, że Nokia wymyślił ScratchBox / Scratchbox2 do bocznej kroku wysoce łamanego Autotools kompilacji konfiguracje dla Maemo / MeeGo). Jeśli z jakiegokolwiek powód, miej stałe, statyczne ścieżki w swoich testach, przerwiesz obsługę kompilacji krzyżowej, ponieważ nie będzie honorować specyfikacji sysroot i wyciągnie rzeczy z twojego systemu hosta. Jeśli przerwiesz obsługę wielu kompilacji, spowoduje to, że Twój kod nie będzie nadawał się do takich rzeczy jak OpenEmbedded i sprawi, że będzie on „zabawny” dla dystrybucji próbujących zbudować swoje wydania na kompilatorze krzyżowym zamiast na celu.
  • Wykonuje OGROMNĄ ilość testów pod kątem problemów ze starożytnymi, zepsutymi kompilatorami, których obecnie NIKT nie używa przy prawie żadnej produkcji w dzisiejszych czasach. O ile nie budujesz czegoś takiego jak glibc, libstdc ++ lub GCC na naprawdę starożytnej wersji Solaris, AIX lub podobnej, testy są stratą czasu i są źródłem wielu, wielu potencjalnych awarii takich rzeczy jak wspomniano powyżej.
  • Przeżycie konfiguracji Autotools do zbudowania użytecznego kodu dla systemu Windows jest bardzo bolesne. (Chociaż niewiele używam w systemie Windows, poważnym problemem jest opracowywanie rzekomo wieloplatformowego kodu).
  • Kiedy się zepsuje, spędzasz GODZIN na pogoni za ogonem, próbując uporządkować rzeczy, które ktoś, kto napisał scenariusz, popełnił błąd, aby uporządkować twoją kompilację (w rzeczywistości to właśnie próbuję zrobić (a raczej całkowicie rozerwij Autotools - Wątpię, czy w pozostałej części miesiąca jest wystarczająco dużo czasu, aby uporządkować bałagan ...) do pracy teraz, kiedy to piszę. Apache Thrift ma jeden z tych ZBŁĘKANYCH systemów kompilacji, które nie przejdą -skompilować.)
  • „Normalni” użytkownicy tak naprawdę NIE zrobią po prostu „./configure; make” - w wielu przypadkach wyciągną pakiet dostarczony przez kogoś, na przykład z PPA, lub od ich dystrybutora. „Normalni” użytkownicy nie są programistami i w wielu przypadkach nie chwytają tarballi. To snobizm ze strony wszystkich za przypuszczenie, że tak właśnie będzie. Typowymi użytkownikami tarballów są deweloperzy, którzy robią różne rzeczy, więc jeśli zostaną, zostaną zaatakowani przez złamanie.

Działa ... przez większość czasu ... to wszystko, co możesz powiedzieć o Autotools. To system, który rozwiązuje kilka problemów, które tak naprawdę dotyczą tylko projektu GNU ... dla ich podstawowego, podstawowego kodu łańcucha narzędzi. (Edytuj (24.05.2014): Należy zauważyć, że tego rodzaju obawy są potencjalnie ZŁĄ rzeczą, o którą należy się martwić - Heartbleed częściowo wywodzi się z tego myślenia i przy prawidłowych, nowoczesnych systemach, naprawdęnie masz nic wspólnego z tym, co koryguje Autotools. GNU prawdopodobnie musi zrobić cruft usuwanie bazy kodu, w świetle tego, co stało się z Heartbleed) Możesz go użyć do wykonania swojego projektu i może działać dobrze w przypadku niewielkiego projektu, który nie powinien działać nigdzie indziej niż Linux lub gdzie łańcuch narzędzi GNU wyraźnie działa poprawnie. Stwierdzenie, że „ładnie integruje się z Linuksem” jest dość odważnym stwierdzeniem i dość niepoprawnym . Całkiem dobrze integruje się z narzędziem GNU i rozwiązuje problemy IT z celami.

Nie oznacza to, że nie ma problemów z innymi opcjami omawianymi w tym wątku.

SCons jest raczej zamiennikiem Make / GMake / etc. i wygląda całkiem ładnie, zważywszy na wszystko Jednak ...

  • Jest to nadal narzędzie bardziej POSIX. Prawdopodobnie łatwiej byłoby przy pomocy MinGW zbudować system Windows przy pomocy Autotools, ale nadal jest on bardziej nastawiony na robienie rzeczy POSIX i aby go użyć , musisz zainstalować Python i SCons.
  • Ma problemy z kompilacją krzyżową, chyba że używasz czegoś takiego jak Scratchbox2.
  • Co prawda wolniejsze i mniej stabilne niż CMake z własnego porównania. Wymyślają negatywne (strona POSIX potrzebuje make / gmake do budowania ...) negatywów dla CMake w porównaniu do SCons. (Nawiasem mówiąc, jeśli potrzebujesz TAKIEJ rozszerzalności w stosunku do innych rozwiązań, powinieneś zadać sobie pytanie, czy twój projekt jest zbyt skomplikowany ...)

Przykłady podane dla CMake w tym wątku są nieco fałszywe.

Jednak...

  • Musisz nauczyć się nowego języka.
  • Istnieją rzeczy sprzeczne z intuicją, jeśli jesteś przyzwyczajony do tworzenia, SCons lub autotools.
  • Musisz zainstalować CMake w systemie, dla którego budujesz.
  • Potrzebujesz solidnego kompilatora C ++, jeśli nie masz gotowych plików binarnych.

Prawdę mówiąc, twoje cele powinny decydować o tym, co wybierzesz tutaj.

  • Czy musisz poradzić sobie z DUŻĄ zepsutych łańcuchów narzędzi, aby stworzyć ważny działający plik binarny? Jeśli tak, możesz rozważyć Autotools, mając świadomość wad, o których wspomniałem powyżej. CMake może sobie z tym poradzić, ale martwi się tym mniej niż Autotools. SCons można rozszerzyć, aby się tym martwić, ale nie jest to odpowiedź gotowa.
  • Czy musisz się martwić o cele systemu Windows? Jeśli tak, Autotools powinny dosłownie przestać działać. Jeśli tak, SCons może / może nie być dobrym wyborem. Jeśli tak, CMake to solidny wybór.
  • Czy musisz się martwić kompilacją krzyżową (uniwersalne aplikacje / biblioteki, rzeczy takie jak Google Protobufs, Apache Thrift itp. POWINIENEś się tym przejmować ...)? Jeśli tak, narzędzia automatyczne mogąpracuj dla Ciebie, dopóki nie musisz martwić się o system Windows, ale poświęcisz dużo czasu na utrzymanie systemu konfiguracji, gdy wszystko się zmieni. SCons jest w tej chwili prawie nie do przyjęcia, chyba że używasz Scratchbox2 - tak naprawdę nie ma żadnego uchwytu na kompilacji krzyżowej i będziesz musiał użyć tej rozszerzalności i utrzymywać ją w taki sam sposób jak zrobisz to z Automake. Jeśli tak, możesz rozważyć CMake, ponieważ obsługuje on kompilację krzyżową bez tylu obaw o wyciekanie z piaskownicy i będzie działał z / bez czegoś takiego jak Scratchbox2 i ładnie integruje się z takimi rzeczami jak OpenEmbedded.

Istnieje wiele powodów, dla których wiele projektów porzuca qmake, narzędzia automatyczne itp. I przenosi się do CMake. Do tej pory mogę spokojnie oczekiwać, że projekt oparty na CMake wpadnie w sytuację kompilacji krzyżowej lub w konfigurację VisualStudio lub będzie potrzebował tylko niewielkiej ilości czyszczenia, ponieważ projekt nie uwzględniał części tylko dla systemu Windows lub OSX do bazy kodów. Nie mogę się spodziewać, że z projektu opartego na SCons - i w pełni oczekuję, że 1/3 lub więcej projektów Autotools popełniło COŚ błędnego, co wyklucza budowanie poprawnie w dowolnym kontekście, z wyjątkiem jednego budującego hosta lub Scratchbox2.


12
Sekcja wspominająca o Heartbleed odwraca uwagę od tego sfrustrowanego postanowienia. Problem polegał na tym, że OpenSSL NIE używał pakietu typu konfigurator do wykrywania uszkodzonych bibliotek systemu Malloc, ale ponownie wdrażał biblioteki systemowe i pokonał programistów platform, którzy stworzyli biblioteki, które znacznie wcześniej wykryłyby wady. Jednym z powodów przenoszenia programów jest to, że stają się one wyższej jakości, ponieważ są mniej zależne od tych małych założeń, których nie zdajesz sobie sprawy, że robisz
Rob11311

9
Chodzi o to, że wcale tego nie umniejsza. Dzięki Autotools martwisz się o rekompensatę za takie rzeczy - te re-implementacje są EKSPANSJĄ tego myślenia. Przenosząc go na wyższy poziom. Powinieneś spojrzeć na to z tego tła ... w którym to momencie wcale to nie umniejsza. Nie wskazałeś głównej przyczyny w swoim rozumowaniu - tylko to, co się stało. Dotykam dokładnie tego MYŚLENIA, które do tego doszło, wraz z Shellshock i kilkoma innymi podobnymi. Jeśli jest zepsuty, NAPRAW go. Jeśli nie możesz - powinieneś zapytać, dlaczego tak jest.
Svartalf,

5
Nie wątpię, że auto-narzędzia i oszustwa są do bani, ale ta odpowiedź źle radzi sobie z zauważeniem wad CMake (mojego preferowanego systemu kompilacji, tylko z powodu bardzo, bardzo smutnego stanu kompilacji). Zasadniczo CMake to fraktal niespójności z wbudowanym wsparciem dla pojedynczych przypadków brzegowych, a nie podstawowa abstrakcja, która obsługuje większość rzeczy. To zdecydowanie taśma klejąca i drut ratunkowy programowania. Jestem pewien, że robię coś źle, ale nie obsługuje VisualStudio, chyba że znajdziesz jeden projekt VS na CMakeLists.txt do zaakceptowania (nie jestem użytkownikiem VS, ale moi Winfriends mówią mi, że to źle).
weberc2

5
W przeciwieństwie do innych znienawidzonych narzędzi programistycznych , nie ma wystarczającej ilości materiałów, aby stworzyć książkę o nazwie „CMake, dobre części” (być może broszurę lub post na blogu), a jest to raczej fraktal złego projektu niż PHP .
weberc2

2
@JAB Użytkownicy VS mówią mi, że to nie jest idiomatyczne. W rzeczywistości CMake został zastąpiony jako system kompilacji dla naszego projektu, ponieważ nikt nie mógł wymyślić, jak utworzyć wspomniane „idiomatyczne” pliki VS Project.
weberc2,

73

Należy rozróżnić, kto korzysta z narzędzi. Cmake to narzędzie, z którego musi korzystać użytkownik podczas tworzenia oprogramowania. Narzędzia automatyczne służą do generowania tarballa dystrybucyjnego, którego można użyć do zbudowania oprogramowania przy użyciu tylko standardowych narzędzi dostępnych w dowolnym systemie zgodnym z SuS. Innymi słowy, jeśli instalujesz oprogramowanie z tarballa, który został zbudowany przy użyciu narzędzi automatycznych, nie używasz narzędzi automatycznych . Z drugiej strony, jeśli instalujesz oprogramowanie korzystające z Cmake, to używasz Cmake i musisz go zainstalować, aby zbudować oprogramowanie.

Zdecydowana większość użytkowników nie musi mieć zainstalowanych narzędzi automatycznych na swoich urządzeniach. Historycznie było wiele nieporozumień, ponieważ wielu programistów rozpowszechnia źle sformułowane pliki archiwów, które zmuszają użytkownika do uruchomienia autoconf w celu zregenerowania skryptu konfiguracyjnego, co jest błędem podczas pakowania. Więcej zamieszania spowodował fakt, że większość głównych dystrybucji Linuksa instaluje wiele wersji autotools, kiedy domyślnie nie powinny instalować żadnej z nich. Jeszcze więcej zamieszania powodują programiści próbujący używać systemu kontroli wersji (np. Cvs, git, svn) do dystrybucji swojego oprogramowania, a nie budowania archiwów.


5
To prawda, choć brzmi to tak, jakby używać VCS do dystrybucji oprogramowania. Jeśli zawartość kasy lub klonu jest taka sama jak zawartość tarballa, dlaczego polecasz tarballi?
d -_- b

5
@Toor Nie rozumiem twojego pytania. Wszystkie projekty, nad którymi pracuję, produkują archiwum, które różni się od kasy VCS. Zachowanie dwóch odrębnych elementów pomaga w niezawodnej dystrybucji.
William Pursell,

13
To prawda, że ​​wiele projektów prosi ludzi o korzystanie z VCS w celu uzyskania najnowszej wersji, ale jest to odpowiednie tylko dla programistów. Niestety, wielu użytkowników nie rozumie różnicy między wydanym archiwum a VCS. Próba zbudowania z VCS narzuca więcej zależności. Użytkownik może potrzebować asciidoclub help2manlub doxygen, co ważniejsze, prawidłowej kombinacji narzędzia automatycznego. Był to ogromny problem marketingowy dla narzędzi automatycznych. Użytkownicy błędnie sądzą, że potrzebują zainstalowanej funkcji autoconf, ponieważ nie rozumieją różnicy między pakietem archiwalnym a VCS.
William Pursell

3
Dlaczego projekt nie może rozpowszechniać danych wyjściowych Cmake, plików projektu i plików Makefile na popularnych platformach, np. Win, Linux i MacOSX? Wygląda na to, że jest tak samo, jak w przypadku narzędzi lex / yacc. Dołączasz genarny kod C, aby można go było budować na platformach bez narzędzi
Rob11311

3
Chociaż uważam, że punkty wymienione w tej dyskusji są poprawne, uważam, że w tej dyskusji nie ma sensu. Użytkownik musi zainstalować całą masę innych rzeczy i to, czy dodatkowa instalacja cmake nie musi być dużym problemem. Martwiłbym się bardziej o biblioteki, łańcuch narzędzi kompilatora i inne narzędzia potrzebne do budowy oprogramowania.
lanoxx

24

Nie chodzi o standardy kodowania GNU.

Obecne zalety autotools - szczególnie w połączeniu z automake - polegają na tym, że bardzo dobrze integrują się one z budowaniem dystrybucji Linuksa.

Na przykład w przypadku cmake zawsze „potrzebowałem -DCMAKE_CFLAGS lub -DCMAKE_C_FLAGS?” Nie, to nie jest, to „-DCMAKE_C_FLAGS_RELEASE”. Lub -DCMAKE_C_FLAGS_DEBUG. Jest to mylące - w autoconf jest to po prostu ./configure CFLAGS = "- O0 -ggdb3" i masz go.

W integracji z infrastrukturami kompilacyjnymi scons ma problem, którego nie można użyć make %{?_smp_mflags}, _smp_mflagsw tym przypadku jest to makro RPM, które z grubsza rozwija się (administrator może to ustawić) moc systemu. Ludzie umieszczają tutaj takie rzeczy jak -jNCPUS w swoim środowisku. W przypadku scons, które nie działają, więc pakiety korzystające z scons mogą być seryjnie wbudowane tylko w dystrybucje.


8
+1, a świat byłby lepszym miejscem, gdyby to była prawda. Niestety ./configure CFLAGS=-O0często zawodzi w przypadku pakietów, które zastępują CFLAGS w pliku makefile i wymagają zamiast tego uruchomienia użytkownika ./configure --enable-debug. (np tmux.).
William Pursell

2
Nie jest to bardziej mylące niż Autotools i jak słusznie zauważył William, zostaje zepchnięty do piekła z niewłaściwie oprawionymi CFLAGS = "<foo>" w pliku makefile. Po prostu jest to kolejny z tych „starych pił”. A przykłady CMake są fałszywe ... znowu ... Możesz zrobić pierwszy, jeśli nie określisz ZWOLNIENIA lub DEBUGI. ZAWIEŚĆ.
Svartalf

17

Ważne jest, aby wiedzieć o Autotools, że nie są one ogólnym systemem kompilacji - implementują standardy kodowania GNU i nic więcej. Jeśli chcesz stworzyć pakiet zgodny ze wszystkimi standardami GNU, Autotools są doskonałym narzędziem do tego zadania. Jeśli tego nie zrobisz, powinieneś użyć Scons lub CMake. (Na przykład zobacz to pytanie .) To powszechne nieporozumienie jest źródłem frustracji związanej z Autotools.


11
Standardy GNU można wyłączyć w Automake za pomocą AUTOMAKE_OPTIONS = -foreignw swoim Makefile.am. (Lub -foreignw twoim autogen.sh. Myślę, że prawie wszyscy tego używają.)
Dietrich Epp

9
Tak, ale to tylko kontroluje, czy Automake wymusza powierzchowne reguły GNU, takie jak to, czy wymagany jest plik README. Nie zmienia to podstawowej przesłanki budowania tarballa w stylu GNU z regułami takimi jak installchecki distclean. Jeśli spróbujesz zmienić tego rodzaju zachowanie podczas korzystania z Autotools, po prostu marnujesz swój czas.
ptomato

1
Pozwalają (teoretycznie) na zbudowanie i zainstalowanie wszystkich pakietów oprogramowania dokładnie w ten sam sposób.
ptomato

Teoretycznie pozwalają lepiej radzić sobie z kompilatorami i systemami operacyjnymi BROKEN niż z innymi narzędziami i stosować powierzchowne reguły, takie jak @ptomato, które zostały tam wyróżnione. Jeśli używasz nowoczesny (powiedzmy GCC lub szczęk ... dla przykładów) narzędzia w nowoczesnym systemie operacyjnym z nic naprawdę Goofy, powiedzmy Linux lub aktualny * BSD, nie POTRZEBUJESZ „zasady” nie. W rzeczywistości wykonują dla ciebie znacznie, dużo więcej pracy i nie mogą pomóc, szczerze mówiąc, w przypadku kompilacji krzyżowej. Prawie połowa wszystkich zastosowań obecnie dotyczy wbudowanego systemu Linux i * BSD. DLACZEGO idziesz z rzeczami, które ci tam nie pomogą?
Svartalf

Nie jesteś pewien, dlaczego głosowałeś za odpowiedzią, skoro zdaje się to potwierdzać w komentarzu ...?
ptomato

9

Podczas gdy z punktu widzenia programistów cmake jest obecnie najłatwiejszy w użyciu, z punktu widzenia użytkownika narzędzia automatyczne mają jedną wielką zaletę

narzędzia automatyczne generują pojedynczy skrypt konfiguracyjny pliku, a wszystkie pliki do jego wygenerowania są dostarczane z dystrybucją. łatwo to zrozumieć i naprawić za pomocą grep / sed / awk / vi. Porównaj to z Cmake, gdzie w / usr / share / cmak * / Modules znajduje się wiele plików, których użytkownik nie może naprawić, chyba że ma on uprawnienia administratora.

Tak więc, jeśli coś nie do końca działa, zwykle można je łatwo „naprawić” za pomocą standardowych narzędzi uniksowych (grep / sed / awk / vi itd.) W sposób młotkowy, bez konieczności rozumienia systemu kompilacji.

Czy kiedykolwiek przekopałeś się przez katalog budowania cmake, aby dowiedzieć się, co jest nie tak? W porównaniu z prostym skryptem powłoki, który można odczytać od góry do dołu, śledzenie wygenerowanych plików Cmake w celu ustalenia, co się dzieje, jest dość trudne. Również w przypadku CMake dostosowanie plików FindFoo.cmake wymaga nie tylko znajomości języka CMake, ale może również wymagać uprawnień administratora.


7
Nie sądzę, że problemy z Autotools można „łatwo naprawić” w porównaniu z CMake ...
sleske

7
Ponieważ narzędzia automatyczne są złożonym systemem (podobnie jak CMake). Jeśli uważasz, że narzędzia automatyczne są „łatwe do naprawienia” (może to być uzasadnione), dobrze byłoby IMHO wyjaśnić w odpowiedzi, w jaki sposób łatwiej jest naprawić problemy.
sleske

5
narzędzia automatyczne generują pojedynczy skrypt konfiguracyjny pliku, a wszystkie pliki do jego wygenerowania są dostarczane z dystrybucją. łatwo to zrozumieć i naprawić za pomocą grep / sed / awk / vi. Porównaj to z Cmake, gdzie w / usr / share / cmak * / Modules znajduje się wiele plików, których użytkownik nie może naprawić, chyba że ma on uprawnienia administratora. Czy kiedykolwiek przekopałeś się przez katalog budowania cmake, aby dowiedzieć się, co jest nie tak? W porównaniu do prostego skryptu shellscript, który można odczytać od góry do dołu, śledzenie wygenerowanych plików Cmake, aby dowiedzieć się, co się dzieje, jest dość trudne
napisał

2
Tak, to ma sens, dzięki. Pozwoliłem sobie dodać to do twojej odpowiedzi. Cofnij się :-).
sleske

1
Zawsze możesz użyć własnej lokalnej wersji cmake; nie ma powodu, aby używać tego, co jest zainstalowane na poziomie systemu. Dla każdego, kto wykonuje prace na różnych platformach, jest to całkowicie normalne; to z pewnością sposób, w jaki najczęściej używam cmake.
James Moore,
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.