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

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

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.

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.

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.

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.

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.