Как организовать хранение библиотек и хидеров от которых зависит наш проект?

Question

[Николай Бекетов]

Разрабатываем различные библиотеки на С++.
Код библиотек храним в репозитории.
Но почти всегда, библиотеки имеют зависимости.
CURL, POCO, OPENSSL, BOOST, ASTERISK, PJSIP и т.д.

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

Сейчас используем сетевую папку примерно с такой структурой

S:\_SharedLib\BOOST\boost_1_57_0
S:\_SharedLib\BOOST\boost_1_60_0
S:\_SharedLib\POCO\1.6.0
S:\_SharedLib\POCO\1.4.7
S:\_SharedLib\OPENSSL\openssl-1.0.2a
S:\_SharedLib\OPENSSL\openssl-1.0.2e
S:\_SharedLib\OPENSSL\openssl-1.0.2f

Есть какая то практика по этому поводу?

Comments

[Алек Оним]

они хЭдеры:)

[Николай Бекетов]

Главное что все поняли о чем вопрос :)

Answer 1

[Freeman]

И чтобы хранилась история, чтобы мы могли взять версию своей библиотеки за прошлый год и быстро ее собрать со всеми зависимостями. Сейчас используем сетевую папку просто.

В SVN есть такая штука, как svn:externals. В Git и Мercurial тоже наверняка есть, а вот в CVS вряд ли.

Суть в том, что в вашем хранилище хранится ссылка на другое (внешнее) хранилище, и при развертывании рабочей копии клиент ходит по этим "символическим ссылкам" и рекурсивно по ним всё скачивает. В SVN подчиненные рабочие копии будут выглядеть как обычные, у них будет своя папка .svn.

Нужно только, чтобы внешнее хранилище было такого же типа, как и ваше. Скажем, SVN не сможет скачать из внешнего Git. Если вы качаете библиотеки не из хранилищ, а просто архив с сайта, заведите у себя отдельное хранилище для библиотек и складывайте туда все нужные версии.

Answer 2

[Алексей Черемисин]

Можно поступать по разному.
Использовать скрипт, с зависимостяти, или просто вставить это в Makefile отдельным таргетом, чтобы можно было вытащить все зависимости.
Или использовать submodules -

https://git-scm.com/book/ru/v1/Инструменты-Git-Подмодули

И перейти с использования CVS и SVN на git или mercurial!

Comments

[xfg]

В C++ нет менеджера зависимостей как в других языках?

[Станислав Макаров]

xfg нет, и видимо не скоро появится.
1. Был biicode, не взлетел.
2. Сейчас пытается взлететь Conan.
3. Непонятно, что нужно от такого менеджера, т.к. C/C++ - языки, близкие к системе, и управление dev-пакетами уже частично реализуется системными менеджерами.

[Алексей Черемисин]

xfg: Э... М.... ы...... нет! Есть менеджеры зависимостей в отдельных IDE, но обычно они работают локально. А интересно, в каких языкакх, кроме новомодных типа Go, есть менеджеры зависимостей? В яве, например, это отдельные инструменты.
Ах, да, есть, но они не совсем менеджеры - autoconfig и pkgconf. Но они не умеют скачивать зависимости. А только скажут, каких зависимостей не хватает.

[Алексей Черемисин]

Ну, и если пишете на каком-то отдельном фреймворке, типа boost, то например вот - www.boost.org/build/index.html

[Станислав Макаров]

Алексей Черемисин Ну если НЕ считать JS новомодным - то NPM, всеми любимый. Ну и в дотнете Нюгет есть)

[Алексей Черемисин]

Станислав Макаров: Проблема в том, что для всех этих языков есть устоявшиеся репозитарии с кодом (для руби/питона/nodejs/java/scala). Но, эти языки еще и интерпретируемые, либо динамические, в большинстве случаев. Другими словами, есть как бы единая точка комьюнити, где лежат куча библиотек и исходников. Для C++/C такого места просто нет. Есть для отдельных фреймворков типа glib/boost/qt и т.д.

[Алексей Черемисин]

Причем, если уж и говорить по JS, то не нужно говорить про инфраструктуру nodeJS! JS - язык программирования, а nodeJS - фреймворк с комьюнити и репозиторием!

Answer 3

[Станислав Макаров]

CMake решит большинство ваших проблем:

https://cmake.org/cmake/help/v3.6/command/find_pac...
CMake:How To Find Libraries

Большинство - кроме проблемы установки/управления зависимыми библиотеками. Т.е. CMake попытается найти в системе нужную версию библиотеки, но установить вы её должны сами. В *nix - системах с этим неплохо справляется системный пакетный менеджер, в Винде всё плохо (т.е. делаем руками).

Comments

[Николай Бекетов]

Часто, собрать зависимые библиотеки уходит много времени. CMAKE позволяет использовать нужное, согласен. Но вопрос больше о том, как правильно организовать хранение уже собранных библиотек, чтобы не компилить их каждый раз. И чтобы хранилась история, чтобы мы могли взять версию своей библиотеки за прошлый год и быстро ее собрать со всеми зависимостями. Сейчас используем сетевую папку просто.