Как правильно управлять зависимостями для проекта C / C ++?

У меня есть проект, который использует 3-4 различных библиотек C / C ++ с открытым исходным кодом.

Я построил эти библиотеки для нескольких платформ и зарегистрировал в своем проекте включаемые файлы и статические библиотеки для разных платформ.

Однако я борюсь с парой проблем. Все эти проекты связаны с управлением зависимостями. И я ищу советы передового опыта.

1) Как узнать, что именно я использую?

У меня нет способа получить версию статической библиотеки. В результате мне нужно как-то отследить, какую версию статической библиотеки я использую (может быть, SHA коммита, из которого она была построена)?

Это особенно важно, когда мне нужно выяснить, когда обновить эти библиотеки.

2) Как воспроизвести сборку?

Я мог бы попытаться создать какую-то конкретную библиотеку для конкретной платформы. Мне понадобилось время, чтобы понять это.

В следующий раз, когда мне нужно будет собрать ту же библиотеку, может быть через полгода (когда мне нужно будет обновить ее по любой причине. Однако к тому времени я точно не вспомню ничего и среду, на которой она была построена) будет давно ушел

3) Стоит ли разветвлять эти библиотеки, чтобы получить копию исходного кода?

Это меньшее беспокойство. Тем не менее, это все еще проблема. Приятно убедиться, что сборки воспроизводимы (и для этого требуется исходный код).

Вам действительно нужно всегда использовать точную версию зависимой библиотеки? Это плохо написано / это ломает его API с каждым незначительным увеличением версии?

Если вы посмотрите на проекты с открытым исходным кодом, их configureсценарии сборки (в основном часть) проверяют наличие различных библиотек и выдают ошибку, если нет. Он также достаточно гибок, чтобы позволить пользователю связываться с более новой версией библиотеки (которая, вероятно, предоставляет больше исправлений ошибок / безопасности, чем более старая), а также не обеспечивает статическое или динамическое связывание.

Если вам действительно нужны воспроизводимые сборки, то вам также следует обратить внимание на точную версию компилятора и его стандартных библиотек, возможно, даже операционной системы. В этом случае, на мой взгляд, лучше иметь машину для сборки с нужной вам средой, чем проверять скомпилированные библиотеки в хранилище исходного кода.

Как я знаю, что именно я использую?

Если включаемые файлы или файлы libs еще не содержат номер версии, добавьте текстовый файл "version.txt" (содержащий номер версии) самостоятельно в каждую папку lib и проверьте его в своей VCS вместе с файлами lib и include , Тем не менее, если вы используете полный исходный код библиотеки (пункт 3), существует высокая вероятность того, что файл исходного кода, содержащий номер версии, уже существует, поэтому в этом случае нет необходимости поддерживать свой собственный.

Как воспроизвести сборку?

Попробуйте автоматизировать столько, сколько сможете. Используйте скрипты, make-файлы или файлы ваших любимых инструментов сборки. Поставьте все это под контроль источников. Если необходимо выполнить шаги вручную, запишите детали в текстовый файл (например, readme_build.txt) и поместите его также под контроль исходного кода.

Должен ли я разветвлять эти библиотеки, чтобы получить копию исходного кода?

Вы должны иметь копию исходного кода , но раскошелиться только в случае необходимости (например, если вы спотыкаетесь срочная ошибкой, и оригинальный автор не может исправить его в течение вашего времени контрсил). Или, если авторы используют среду компилятора, отличную от вас, и необходимо внести некоторые изменения, чтобы библиотека работала в вашей среде. Однако имейте в виду, что каждое изменение исходного кода в вашем форке, скорее всего, затрудняет интеграцию обновлений в более позднее время.

Тем не менее, я рекомендую получить копию исходного (не разветвленного) исходного кода используемых вами библиотек. Это позволит вам впоследствии разветвлять или поддерживать библиотеку, если в этом возникнет необходимость, даже если первоначальный сопровождающий решит отозвать исходные коды библиотеки из общедоступной сети.