C ++ Build Systems - Czego używać? [Zamknięte]

Patrzę na rozpoczęcie nowego projektu w C ++ - początkowo tylko w swoim czasie - i badam dostępne systemy kompilacji. Wydawałoby się, że odpowiedź brzmi: „Wiele i wszystkie są okropne”.

Funkcje, których szczególnie potrzebuję, to:

1. Obsługa C ++ 11
2. Wieloplatformowy (Linux jako główny cel, ale może również zbudować przynajmniej na Windows)
3. Przyzwoite wsparcie dla testów jednostkowych
4. Obsługa wielu modułów do oddzielania kodu
5. Wsparcie dla generowania kodu (przy użyciu asn1c lub protobuf - jeszcze nie w 100%)
6. Łatwe w utrzymaniu

Teraz wiem, że mogę z łatwością wykonać 1-4 z tych za pomocą CMake i Autotools. Prawdopodobnie także z SCons i Waf oraz kilkoma innymi. Problem w tym, że nigdy nie wymyśliłem, jak poprawnie generować kod za ich pomocą - czyli pliki źródłowe, które nie istnieją do czasu pierwszego uruchomienia procesu kompilacji, więc pliki źródłowe, które system kompilacji musi być w stanie przekonwertować na kod wykonywalny ale tak naprawdę nie wie o tym do momentu uruchomienia kompilacji ... (w szczególności ASN1C generuje dziesiątki plików nagłówkowych i źródłowych, które muszą być w stanie ze sobą współpracować, a rzeczywisty zestaw generowanych plików zależy od zawartości twojego pliku asn). również fakt, że żadna z nich nie jest szczególnie łatwa w utrzymaniu - CMake i Autotools mają własny, ogromny zestaw skryptów, którymi trzeba zarządzać, aby działały,

Więc - jakie systemy kompilacji są zalecane do czegoś takiego? A może na razie utknę z tworzeniem plików i skryptami powłoki?

+1 za „Wiele i są okropne”.

Jednak „najbogatszym” i „najbardziej skalowalnym” jest prawdopodobnie CMake , który jest generatorem plików Makefile (generuje również natywny MSVC ++ *.proj/ *.sln). Dziwna składnia, ale kiedy już się jej nauczysz, możesz ładnie generować kompilacje dla różnych platform. Gdybym „zaczął od nowa”, prawdopodobnie użyłbym CMake. Powinien obsłużyć twoją listę, chociaż "generowanie kodu" może zająć "własne życie" poza systemem budowania, w zależności od tego, co chcesz zrobić. (Zobacz poniżej.)

W przypadku prostych projektów generator QMake jest w porządku (nie musisz używać bibliotek Qt, aby używać QMake). Ale nie opisujesz „prostego” - generowanie kodu i „dodatkowe fazy” oznacza, że ​​prawdopodobnie potrzebujesz CMakeczegoś z bogatym API dla własnych rozszerzeń, takich jak Scons(lub Waf).

Używamy Sconsów w pracy. Tworzy "kuloodporne kompilacje", ale działa bardzo wolno. Żaden inny system nie będzie tak kuloodporny jak Scons. Ale jest powolny. Jest napisany w Pythonie i rozszerzyliśmy interfejs dla naszej „organizacji przestrzeni roboczej” (gdzie określamy jedynie zależności modułów) i jest to część Sconszałożeń projektowych (ten typ rozszerzenia poprzez Python). Wygodne, ale kompilacje są powolne. Otrzymujesz kuloodporne kompilacje (każde pudełko programisty może wydać ostateczną wersję), ale jest wolne. I jest powolny. Nie zapominaj o tym, jeśli używaszScons , to działa wolno. I jest powolny.

Źle mi się wydaje, że dekadę po 2000 roku nadal nie mamy latających samochodów. Prawdopodobnie będziemy musieli poczekać kolejne sto lat, aby je zdobyć. I wtedy prawdopodobnie wszyscy będziemy latać w naszych latających samochodach, które wciąż są konstruowane z kiepskimi systemami.

Tak, wszystkie są okropne.

[O GENEROWANIU KODU]

Sconsdziała na „fazach” i są one „nieco statyczne”. Potrafi zbudować kod, który jest generowany jako część kompilacji (ludzie robią to na kilka różnych sposobów), ale zostało to opisane jako „coś bardzo nie podobnego do Sconsa”.

Jeśli jest to proste "przetwórz wstępnie niektóre pliki i wygeneruj pliki źródłowe", to nic wielkiego (masz wiele opcji i dlatego qmakezostało napisane - do mocwstępnego przetwarzania*.hpp/*.cpp plików).

Jeśli jednak robisz to w „ciężki sposób”, będziesz musiał napisać własny skrypt. Na przykład mieliśmy skrypty jako część kompilacji, które odpytywały bazy danych i generowały klasy C ++ w celu połączenia między „warstwami” (w tradycyjnym trójwarstwowym tworzeniu aplikacji). Podobnie wygenerowaliśmy kod źródłowy serwera / klienta za pomocą IDL i wbudowanych informacji o wersji, aby umożliwić jednoczesne działanie wielu klientów / serwerów z różnymi wersjami (dla tego samego „klienta” lub „serwera”). Dużo wygenerowanego kodu źródłowego. Moglibyśmy „udawać”, że jest to „system-kompilacji”, ale tak naprawdę jest to nietrywialna infrastruktura do „zarządzania konfiguracją”, której częścią jest „system budowania”. Na przykład ten system musiał „zdjąć” i „

Możesz teraz używać Gradle: https://docs.gradle.org/current/userguide/native_software.html

Wydaje się, że to trochę dojrzało przez lata, odkąd to opublikowałem. Strona informująca o „inkubacji projektu” zniknęła, ale nie mogę znaleźć żadnego oficjalnego komunikatu usuwającego ten stan.

Znalazłem te, nie wykorzystałem jeszcze osobiście wszystkich:

Ninja , mały system budowania skoncentrowany na szybkości. Google używa teraz Ninja do budowania Androida zamiast Make: link .

Shake , potężny i szybki system budowania.

Tup , system kompilacji o wysokiej wydajności. Projektowanie oparte na algorytmach . Analiza Tup .

Wszystkie są teraz wieloplatformowe i obsługują system Windows. Nie jestem jeszcze pewien co do pozostałych wymagań, ponieważ ponownie nie przetestowałem ich jeszcze osobiście. Są wykorzystywane w rozwoju komercyjnym, CIG wybrał Ninja. Używałem i kocham łatwość i szybkość Ninja z generatorem projektów. Pierwsze dwa są podobne do Scons, Ant itp.

Scons to bardzo przyjazny i elastyczny system, ale masz rację, Lothar, działa bardzo wolno.

Istnieje jednak sposób na zwiększenie wydajności programów napisanych w Pythonie. Takie wykorzystanie JIT. Ze wszystkich znanych projektów, PyPy jest bardzo potężną, szybko rozwijającą się i zmotywowaną implementacją Pythona 2.7, opartą na JIT. Kompatybilność PyPy z Pythonem 2.7 jest po prostu niesamowita. Jednak Scons zadeklarowany jako nieobsługiwany projekt na wiki zgodności PyPy . Z drugiej strony Waf , modelowany jako następca autotools oparty na Pythonie, jest w pełni obsługiwany przez infrastrukturę PyPy. W moich projektach szybkość montażu wzrosła 5-7 razy w przejściu na PyPy. Możesz zobaczyć raporty wydajności z PyPy .

W przypadku nowoczesnego i stosunkowo szybkiego systemu Waf jest dobrym wyborem.

System kompilacji Google to dobra alternatywa: http://bazel.io/

Użyłem SCons i jestem pod wrażeniem tego systemu kompilacji. SCons jest rozszerzalny przez Pythona i sam Python - jest świetny, ponieważ Python ma wszystko, czego potrzebujesz, po prostu zakoduj logikę, cała funkcjonalność niskiego poziomu jest już zaimplementowana w SCons i Pythonie i jest wieloplatformowa. Jeśli masz dobre umiejętności programistyczne, twoje skrypty budujące będą wyglądać idealnie i łatwo.

Make, CMake i podobne systemy kompilacji wyglądają jak śmieć makr. Waf jest analogiem SCons. Próbuję Waf, ale SCons będzie bardziej przyjazny, więc zostałem z SCons.

Według opinii tłumu SCons jest zbyt wolny, ale w środku projektu nie widziałem żadnej różnicy między marką a SCons pod względem szybkości kompilacji. Zamiast tego SCons dobrze działał z równoległymi kompilacjami, podczas gdy make ma z tym duże problemy.

Ponadto SCons umożliwia pobieranie - konfigurowanie, budowanie, wdrażanie, generowanie konfiguracji z szablonów, uruchamianie testów i wykonywanie wszelkich innych zadań, które można wykonać, np. Kodowanie w Pythonie i SCons - wszystko w jednym. To bardzo duża zaleta.

W przypadku prostego projektu CMake to również dobry wybór.

żeby dodać moje centy: premake

http://industriousone.com/premake

na wiki znajduje się również dedykowana strona internetowa .

Możesz użyć Ceedling . Należy jednak pamiętać, że obecnie obsługuje on tylko C i jest ściśle powiązany z autorskimi frameworkami testowymi Unity i CMock.

Można go dość łatwo rozwidlać i modyfikować, aby działał z kompilatorem C ++ i frameworkiem testowania jednostkowego / symulowania.

Również Tup jest godne wzmianki. Jest niezwykle szybki, ale nic nie wie o testowaniu frameworków itp., Co oznacza, że ​​będziesz musiał napisać własny system kompilacji za pomocą Tup. Jeśli planujesz robić TDD, prawdopodobnie najlepszym rozwiązaniem jest Tup.