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ć?
źródło
mavencały punktmavenlub 10 lat temu, kiedy nie używałemmavenw C ++, było to znacznie mniej przydatne w C ++. Nie mogę mówić o 2009 roku, ale z doświadczenia z ostatnich latmavenwynika , że jest to dokładnie to, czego użyłbyś do opisanego problemu. Robi dokładnie to, czego chcesz, całkiem skutecznie i dobrze, i nie robi tych negatywnych rzeczy, o których twierdzisz, że robi. Każdy, kto czyta to w 2019 lub później, powinien zdecydowanie rozważyć użyciemavenw tym celu.Odpowiedzi:
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ć:
Uwaga, jak wskazał @RAM w komentarzach, cpm nie jest już aktywnie utrzymywany.
źródło
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)
źródło
Polecam następujące systemy kompilacji wysokiego poziomu:
źródło
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.
źródło
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źródło
${CC} ${CFLAGS} -c $< -MD -MF $(<:%.c=%.dep) -o $@Trudno mi było przeanalizować wszystkie te symbole Make, wygląda na to, że rozwiązuje się to na przykład,g++ -c main.cc -MD -MF testjeśli chcesz uruchomić go samodzielnie w wierszu poleceń, a wyniki umieszcza w pliku o nazwie „test”.Edytować:
Biicode jest przestarzały
Alternatywa: Conan.io
źródło
Polecam conan , z którego ostatnio korzystałem. Utrzymanie wszystkich zależnych bibliotek i plików binarnych w projekcie jest bardzo potężne.
źródło
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 ++
źródło
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”.
źródło
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.
źródło
Zalecam użycie matki wszystkich systemów zależności kompilacji: make.
źródło
Spróbuj babeczek, będziesz uzależniony. Marka jest przestarzała, trudna i droga w utrzymaniu.
źródło