Jak właściwie zarządzać zależnościami dla projektu C / C ++?

Mam projekt, który wykorzystuje 3-4 różne biblioteki C / C ++ typu open source.

Zbudowałem te biblioteki dla kilku platform i zameldowałem się w plikach i bibliotekach statycznych dla różnych platform w moim projekcie.

Walczę jednak z kilkoma problemami. Wszystkie te projekty dotyczą zarządzania zależnościami. I szukam porady najlepszych praktyk.

1) Skąd mam wiedzieć, czego dokładnie używam?

Nie mam drogi, aby uzyskać wersję statycznej biblioteki lib. W rezultacie potrzebuję w jakiś sposób śledzić, której wersji statycznej biblioteki lib używam (może to być SHA zatwierdzenia, z którego została zbudowana)?

Jest to szczególnie ważne, gdy muszę dowiedzieć się, kiedy zaktualizować te biblioteki.

2) Jak odtworzyć kompilację?

Mógłbym mieć problemy z budowaniem konkretnej biblioteki dla konkretnej platformy. Zajęło mi to trochę czasu, aby to rozgryźć.

Następnym razem, gdy będę musiał zbudować tę samą bibliotekę, może upłynąć pół roku (kiedy będę musiał dokonać aktualizacji z jakiegokolwiek powodu. Jednak do tego czasu na pewno nie będę niczego pamiętać i środowiska, na którym została zbudowana) już dawno zniknie.

3) Czy powinienem rozwidlać te biblioteki, aby mieć kopię kodu źródłowego?

To mniejszy problem. Jednak nadal jest to problem. Miło jest upewnić się, że kompilacje są odtwarzalne (i tego rodzaju wymaga kodu źródłowego).

Czy naprawdę musisz zawsze używać dokładnej wersji biblioteki zależnej? Czy jest źle napisany / czy psuje interfejs API przy każdym drobnym wzroście wersji?

Jeśli spojrzysz na projekty typu open source, ich configureskrypty kompilacji ( głównie częściowo) sprawdzają, czy istnieją różne biblioteki i generują błąd, jeśli nie. Jest także wystarczająco elastyczny, aby umożliwić użytkownikowi połączenie z nowszą wersją biblioteki (która prawdopodobnie zapewnia więcej poprawek błędów / zabezpieczeń niż starsza), a także nie wymusza łączenia statycznego lub dynamicznego.

Jeśli naprawdę potrzebujesz odtwarzalnych kompilacji, powinieneś również zwrócić uwagę na dokładną wersję kompilatora i jego standardowych bibliotek, być może nawet systemu operacyjnego. W takim przypadku posiadanie maszyny kompilacji z dokładnie wymaganym środowiskiem jest moim zdaniem lepsze niż sprawdzanie skompilowanych bibliotek w repozytorium kodu źródłowego.

Skąd mam wiedzieć, czego dokładnie używam?

Jeśli pliki dołączania lub pliki libs nie zawierają jeszcze numeru wersji, dodaj plik tekstowy „version.txt” (zawierający numer wersji) samodzielnie do każdego folderu lib i zaznacz go w swoim VCS, wraz z plikami lib i dołącz . Jeśli jednak zaktualizujesz pełne źródło biblioteki lib (punkt 3), istnieje duże prawdopodobieństwo, że plik kodu źródłowego zawiera już numer wersji, więc w tym przypadku nie musisz utrzymywać własnego.

Jak odtworzyć kompilację?

Spróbuj zautomatyzować jak najwięcej. Używaj skryptów, plików makefile lub plików swoich ulubionych narzędzi do budowania. Umieść to wszystko pod kontrolą źródła. Jeśli wymagane są ręczne kroki, zapisz szczegóły w pliku tekstowym (na przykład readme_build.txt) i przekaż to również kontroli źródła.

Czy należy rozwidlać te biblioteki, aby uzyskać kopię kodu źródłowego?

Powinieneś mieć kopię kodu źródłowego , ale rozwidlaj ją tylko w razie potrzeby (na przykład, jeśli natkniesz się na pilny błąd, a oryginalny autor nie może go naprawić w ograniczeniach czasowych). Lub, jeśli autorzy używają innego środowiska kompilatora niż ty, i konieczne jest wprowadzenie pewnych zmian, aby lib działał w twoim środowisku. Należy jednak pamiętać, że każda zmiana oryginalnego kodu źródłowego w rozwidleniu najprawdopodobniej utrudnia późniejszą integrację aktualizacji.

Niemniej jednak polecam, aby uzyskać kopię oryginalnego (odkorkowanego) kodu źródłowego używanych bibliotek. Umożliwi to późniejsze rozwidlenie lub utrzymanie biblioteki lib, jeśli stanie się to konieczne, nawet jeśli oryginalny opiekun zdecyduje się odwołać źródła lib z publicznej sieci.