Ответ
Да, обязательно. Для современных C++ проектов использование пакетных менеджеров — это стандарт, который решает проблему управления зависимостями.
Мой стек и подход:
- vcpkg: Основной инструмент для проектов под Windows/Linux. Отлично интегрируется с CMake через
find_package. Использую манифестный режим (vcpkg.json) для фиксации версий.// vcpkg.json { "dependencies": [ "fmt", "spdlog", { "name": "boost-asio", "version>=": "1.82.0" } ] } - Conan: Выбираю для более сложных сценариев, особенно когда нужны кастомные опции сборки зависимостей или работа в кросскомпиляции.
- CMake + FetchContent: Для лёгких header-only библиотек или внутренних модулей.
Практический пример настройки: В CI/CD пайплайне сборка начинается с восстановления зависимостей через vcpkg, что гарантирует одинаковые версии библиотек у всех разработчиков и на сервере. Это устраняет классическую проблему «а у меня на машине собирается».
Выгоды:
- Воспроизводимость сборки: Фиксация версий зависимостей.
- Ускорение онбординга: Новый разработчик делает
git clone,cmake --preset=release— и всё собирается. - Контроль над зависимостями: Легко обновлять, тестировать с новыми версиями и отслеживать уязвимости (через
vcpkg audit).
Без пакетного менеджера поддержка сторонних библиотек в C++ превращается в рутину с ручным скачиванием, патчами и проблемами совместимости.
Ответ 18+ 🔞
Слушай, а то некоторые до сих пор думают, что в современном C++ можно таскать библиотеки в папку third_party и коммитить в гитик. Это ж ёперный театр, чувак! Пакетные менеджеры — это теперь как чистые зубы по утрам, обязаловка, иначе воняет проектом из 2002-го года.
На чём я катаюсь:
- vcpkg: Моя основная тачка, особенно под Windows. Интеграция с CMake через
find_package— просто песня. Я всегда юзаю манифестный режим (vcpkg.json), чтобы версии были зафиксированы. Иначе один обновилspdlog— и у всей команды сборка накрылась медным тазом.// vcpkg.json — тут всё серьёзно, без фокусов { "dependencies": [ "fmt", "spdlog", { "name": "boost-asio", "version>=": "1.82.0" } ] } - Conan: Беру на передовую, когда нужна хитрая настройка зависимостей или кросскомпиляция. Мощная штука, но и возни с ней овердохуища.
- CMake + FetchContent: Для каких-нибудь простых header-only либ или своих внутренних модулей — самое то, чтобы не городить огород.
Как это в жизни выглядит?
Вот представь: новый чел приходит в команду. Раньше ему надо было полдня искать, какой архив libpng качать и куда его распихивать. А сейчас? git clone, потом cmake --preset=release, и всё, блядь, собирается. В CI/CD такая же история — зависимости ставятся на чистой машине за секунды, версии одинаковые. Доверия к процессу — ебать, на уровне!
Что это даёт, если по-простому:
- Стабильность, мать её: Версии зафиксированы. Сегодня собралось, завтра соберётся. Никаких сюрпризов.
- Скорость въезда: Онбординг новых людей перестаёт быть пиздецом.
- Контроль: Обновил версию в одном файле, протестил — и можно пушить. Да ещё и уязвимости через
vcpkg auditможно ловить.
А без этого — это ж сплошной ручной труд, как в каменном веке: скачивай, распаковывай, патчи пили, решай проблемы совместимости. Да похуй, что у тебя там архитектура чистая, если зависимости подтягиваются через жопу.