Zarządzanie zależnościami w stylu Mavena dla C ++? [Zamknięte]

Powiedzmy, że mam projekt C ++, który jest podzielony na kilka podprojektów. Wszystkie podprojekty tworzą bibliotekę DLL, a różne zespoły programistów pracują nad każdym z podprojektów. Jeśli teraz chcę zbudować główny projekt, czy jest sposób, aby uniknąć konieczności samodzielnego tworzenia wszystkich podprojektów?

Krótko mówiąc, szukam czegoś, co zarządza zależnościami (np. Dla plików binarnych i nagłówków) w podobny sposób, jak robi to Maven dla Javy.

W rzeczywistości próbowałem użyć do tego Mavena, ale jest to raczej kłopotliwe, ponieważ muszę tworzyć pakiety ręcznie i dość często, Maven pomija ostatnie zmiany. Również uruchomienie kompilacji jest trochę hackem, ponieważ muszę wywołać NAnt z poziomu Mavena (używam funkcji NAnt do bezpośredniego tworzenia rozwiązań Visual Studio).

Jakieś wskazówki i pomysły, jak to zrobić?

Pierwsza odpowiedź : Sugerowałbym użycie CMake. Jest to wieloplatformowy generator plików make (generuje również projekty Visual Studio lub Eclipse CDT).

http://www.cmake.org/

Miałem z tym naprawdę dobre doświadczenia. Najbardziej podoba mi się możliwość tworzenia ogólnej struktury projektu. Możesz więc generalnie uwzględniać wyszukiwanie podprojektów pod kątem testów jednostkowych itp. Bez każdorazowej zmiany skryptu.

Mają również wiele modułów, w jaki sposób znaleźć wstępnie zainstalowane biblioteki kompilacji, wymagane dla projektu (takie jak Boost, QT itp.)

Aktualizacja : W międzyczasie próbowano wprowadzić zarządzanie pakietami dla C ++. Niektóre projekty, którym warto się przyjrzeć:

• conan.io integruje się z głównymi narzędziami do kompilacji:
  • CMake
  • Visual Studio
  • Makefile
  • XCode
  • ...
• cpm na podstawie CMake ( Uwaga: CPM nie jest aktywnie utrzymywany).
• Buckaroo

Uwaga, jak wskazał @RAM w komentarzach, cpm nie jest już aktywnie utrzymywany.

Do zarządzania zależnościami istnieje nowy projekt (jest to firma startupowa) wdrażający tego typu narzędzie: https://github.com/biicode (menedżer zależności C ++). Możesz dodać swoje zależności i powinno działać.

Obecnie projekt nosi nazwę conan.io , zostały przejęte przez JFrog .

AKTUALIZACJA: Projekt jest martwy ... Niestety wydaje się, że startup nie mógł zdobyć wystarczającej liczby klientów płacących premium, ale serwer wydaje się działać dobrze ...

UPDATE2: Wygląda na to, że istnieje projekt zastępczy: conan.io (dzięki @mucaho)

Polecam następujące systemy kompilacji wysokiego poziomu:

• Wtyczka Maven Nar: Używanie Maven do projektów C / C ++
• Wtyczka Gradle cpp : Jest to prostszy sposób, ale obecnie się inkubuje, tutaj główne funkcje i mapa drogowa .
• Conan jest bardziej podejściem C ++, jest wieloplatformowy i obsługuje większość popularnych systemów kompilacji C ++.

Jeśli chcesz tylko zarządzania zależnościami, wypróbuj Ivy , ładnie integruje się z Ant (i zakładam, że NAnt może zrobić to samo na podstawie tego bloga , do którego link znajduje się na stronie Ivy).

Jest też Byldan , wersja Maven .Net. Nie wiem jednak, jak dobrze to zadziała.

Make i GCC to świetne połączenie do naprawdę dobrego sprawdzania zależności.

GCC może automatycznie generować pliki zależności „make” (przełącznik wiersza poleceń -MD), aby na przykład móc odbudować wszystkie pliki źródłowe zależne od danego nagłówka.

Mam kilka prostych zasad, które wycinam i wklejam do moich plików makefile:

# compile c files   
%.o:    %.c
    ${CC} ${CFLAGS} -c $< -MD -MF $(<:%.c=%.dep) -o $@

# compile c++ files
%.opp:  %.cpp
    ${CPP} ${CPPFLAGS} -c $< -MD -MF $(<:%.cpp=%.dep) -o $@

Teraz, jeśli twoje pliki obiektowe są zadeklarowane na przykład na liście OBJ_C i OBJ_CPP:

.PHONY: cleandep
cleandep:
    rm -f $(OBJ_C:%.o=%.dep) $(OBJ_CPP:%.opp=%.dep)

-include $(OBJ_C:%.o=%.dep) $(OBJ_CPP:%.opp=%.dep)

Make może oczywiście śledzić zależności z innymi projektami i tym podobne, np. Odbudować współdzieloną bibliotekę, jeśli jest to konieczne.

Na przykład, jeśli inne zespoły zawsze umieszczają swoje najnowsze biblioteki DLL w jakimś udostępnionym folderze:

myapp: ${SRC_CPP} ${LIB_DIR}other_team.lib
  ...

${LIB_DIR}other_team.lib: /shared_folder/latest/other_team.lib
  cp /shared_folder/latest/other_team.lib ${LIB_DIR}other_team.lib

Edytować:

Biicode jest przestarzały

Alternatywa: Conan.io

Polecam conan , z którego ostatnio korzystałem. Utrzymanie wszystkich zależnych bibliotek i plików binarnych w projekcie jest bardzo potężne.

Możesz utworzyć pakiet NuGet dla używanych bibliotek i użyć NuGet do zarządzania zależnościami.

Zobacz także NuGet dla C ++

Na SCons znajduje się wiele narzędzi, które zapewniają wyższą funkcjonalność podobną do tej z Autotools, które starają się ułatwić życie programistom (np. WAF, SNOCS). Niestety sam SCons ma poważną wadę - dłuższy czas kompilacji dla dużych projektów.

Mogę polecić wypróbowanie SNOCS (który jest odwróconym SCons) dla tych z Was, którzy szukają łatwego zarządzania zależnościami i wybrania opcji kompilacji w jednym poleceniu (kompilator, x86 / x64, Debug / Release, biblioteki statyczne / współdzielone, test / zainstalować cele itp.).

SNOCS próbuje również rozwiązać problem długiego czasu kompilacji, przechowując dane wyjściowe konfiguracji projektu w oddzielnych plikach, co pozwala kolejnym kompilacjom na całkowite pominięcie fazy konfiguracji i przejście bezpośrednio do fazy budowy (ostatnia funkcja jest teraz w budowie)

Konfiguracja CMake staje się uciążliwa w większych rozwiązaniach, więc konserwacja systemu kompilacji zajmuje dużą część czasu programisty. Na szczęście, jak wspomniał Martijn, istnieje biikod który „używa CMake do generowania projektu wraz z jego zależnościami”.

Próbować SCons

SCons to narzędzie do tworzenia oprogramowania typu Open Source - to znaczy narzędzie do budowania nowej generacji. Pomyśl o SCons jako ulepszonym, wieloplatformowym zamienniku klasycznego narzędzia Make ze zintegrowaną funkcjonalnością podobną do autoconf / automake i pamięci podręcznych kompilatora, takich jak ccache. Krótko mówiąc, SCons to łatwiejszy, bardziej niezawodny i szybszy sposób tworzenia oprogramowania.

Zalecam użycie matki wszystkich systemów zależności kompilacji: make.

Spróbuj babeczek, będziesz uzależniony. Marka jest przestarzała, trudna i droga w utrzymaniu.