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

У мене є проект, який використовує 3-4 різні бібліотеки C / C ++ з відкритим кодом.

Я створив ці бібліотеки для декількох платформ і зареєстрував у своєму проекті включення файлів та статичних ліб для різних платформ.

Однак я борюся з парою проблем. Усі ці проекти є навколо управління залежностями. І я шукаю поради щодо найкращих практик.

1) Як я знаю, що саме я використовую?

У мене немає способу отримати версію статичної вкладки. Як результат, мені потрібно якось відстежити, яку версію статичної lib я використовую (можливо, це SHA комітету, з якого вона побудована)?

Це особливо важливо, коли мені потрібно розібратися, коли оновити ці лібси.

2) Як я відтворюю збірку?

Я міг би боротися за створення певної бібліотеки для певної платформи. Мені знадобилося певний час, щоб це зрозуміти.

Наступного разу, коли мені буде потрібно будувати ту саму бібліотеку, можна буде через півроку (коли мені потрібно буде оновити з будь-якої причини. Однак до того часу я точно не буду згадувати нічого і середовище, на якому вона була побудована давно пропаде.

3) Чи повинен я роздрібнити ці бібліотеки, щоб вони мали копію вихідного коду?

Це менша стурбованість. Однак це все ще турбує. Приємно переконатися, що збірки відтворюються (і для такого типу потрібен вихідний код).

Вам справді потрібно завжди використовувати точну версію залежної бібліотеки? Це погано написано / чи порушує це API з кожним незначним збільшенням версії?

Якщо ви подивитеся на проекти з відкритим кодом, їх configureсценарії збірки (в основному частини) перевіряють наявність різних бібліотек і видають помилку, якщо ні. Він також є досить гнучким, щоб дозволити користувачеві зв’язуватися з новою версією бібліотеки (яка, ймовірно, забезпечує більше виправлень помилок / безпеки, ніж старіша), а також не застосовує статичне або динамічне посилання.

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

Як мені знати, що саме я використовую?

Якщо файли, що включають файли або файли libs, вже не містять номер версії, додайте текстовий файл "version.txt" (містить номер версії) самостійно до кожної папки lib та перевірте його у свій VCS разом із lib та додайте файли . Однак якщо ви оновлюєте повне джерело lib (пункт 3), швидше за все, вже існує файл вихідного коду, що містить номер версії, тому не потрібно підтримувати свій власний для цього випадку.

Як відтворити збірку?

Постарайтеся автоматизувати скільки завгодно. Використовуйте сценарії, файли чи файли улюблених інструментів побудови. Покладіть це все під контроль джерел. Якщо потрібні кроки вручну, запишіть їх у текстовий файл (наприклад, readme_build.txt) і поставте це також під контроль джерела.

Чи повинен я роздрібнити ці бібліотеки, щоб вони мали копію вихідного коду?

У вас повинна бути копія вихідного коду , але розщедритися лише за необхідності (наприклад, якщо ви натрапите на термінову помилку, і оригінальний автор не може її виправити протягом своїх контракту). Або якщо автори використовують інше середовище компілятора, ніж ви, і необхідно внести деякі зміни, щоб lib працював у вашому оточенні. Однак майте на увазі, що кожна зміна вихідного вихідного коду у вашій вилці, швидше за все, ускладнює інтеграцію оновлень пізніше.

Тим не менш, я рекомендую отримати копію оригінального (невиправленого) вихідного коду використовуваних вами. Це дозволить вам розкрутити або зберегти lib пізніше, якщо це стане необхідним, навіть якщо оригінальний сервіс вирішить відкликати джерела lib з загальнодоступної мережі.