Пакетні менеджери для C++: vcpkg, Conan, CPM та системні пакети

У попередній лекції розглянули способи підключення бібліотек з боку CMake: find_package, FetchContent, ручні шляхи. Усі вони мають спільну проблему: хтось має встановити бібліотеку, а CMake лише її знаходить. Пакетний менеджер бере на себе саме цю частину.

Що таке пакетний менеджер

Пакетний менеджер — це інструмент, який автоматизує встановлення, оновлення та керування бібліотеками (залежностями) проєкту. У більшості мов він давно став стандартом:

C++ довго не мав такого інструмента, бо мова не визначає ні формату пакета, ні системи збірки: одна бібліотека збирається через CMake, інша через Make, третя через Meson або власний скрипт. Через це поява єдиного менеджера була технічно складною задачею, і зараз існує кілька конкуруючих рішень.

Навіщо він потрібен

Без пакетного менеджера

Щоб підключити одну бібліотеку, доводиться виконати такі кроки:

1. Знайти бібліотеку в інтернеті.
2. Завантажити вихідний код.
3. Прочитати документацію, як її компілювати.
4. Скомпілювати бібліотеку (з потрібним компілятором і прапорцями).
5. Прописати шляхи в CMakeLists.txt.
6. Повторити для кожної залежності, і для кожної залежності залежності.
7. При оновленні повторити все знову.

Складність зростає, бо бібліотеки залежать одна від одної. Бібліотека spdlog вимагає fmt, яка, у свою чергу, має власні вимоги. Кожен такий ланцюжок потрібно зібрати вручну, враховуючи сумісність версій.

З пакетним менеджером

vcpkg install fmt spdlog nlohmann-json

Одна команда: менеджер знаходить усі потрібні залежності, збирає їх у правильному порядку з потрібними прапорцями й готує до підключення з CMake.

Огляд менеджерів

Підхід «збірка з джерел» і «готові бінарники»

Ключова відмінність між менеджерами — що саме завантажується:

• Збірка з джерел (основний режим vcpkg): менеджер завантажує код і збирає його вашим компілятором із вашими налаштуваннями. Це гарантує сумісність, але перший раз довго. Кеш збережених результатів (binary cache) прибирає повторне очікування.
• Готові бінарні пакети (основний режим Conan): менеджер завантажує вже зібрану бібліотеку для вашої комбінації платформи, компілятора й конфігурації. Швидко, якщо така комбінація є на сервері, інакше збирається з джерел.

Для C++ збірка з джерел має вагомий аргумент: бінарна сумісність залежить від компілятора, його версії, стандарту, режиму Debug/Release, типу рантайма. Бібліотека, зібрана в іншій комбінації, може не злінкуватись або тихо ламатися під час виконання.

Conan: базове використання

Conan — зрілий менеджер, який поширений у великих командах і в корпоративному середовищі.

pip install conan
conan profile detect

uv tool install conan
conan profile detect

brew install conan
conan profile detect

Команда conan profile detect визначає ваш компілятор і записує профіль за замовчуванням. Залежності описуються у файлі conanfile.txt у корені проєкту:

[requires]
fmt/11.0.2
spdlog/1.14.1

[generators]
CMakeDeps
CMakeToolchain

[layout]
cmake_layout

Секція [requires] перелічує пакети та версії, [generators] каже, які файли для CMake створити, [layout] задає розташування згенерованих файлів. CMakeLists.txt при цьому не знає про Conan:

cmake_minimum_required(VERSION 3.15)
project(MyApp CXX)

set(CMAKE_CXX_STANDARD 17)

find_package(fmt REQUIRED)
find_package(spdlog REQUIRED)

add_executable(MyApp main.cpp)
target_link_libraries(MyApp PRIVATE fmt::fmt spdlog::spdlog)

Збірка:

# 1. Завантажити і зібрати залежності
conan install . --build=missing

# 2. Скористатися згенерованим пресетом CMake
cmake --preset conan-release
cmake --build --preset conan-release

Прапорець --build=missing означає: якщо готового бінарного пакета для вашої конфігурації немає, зібрати його з джерел. Команда conan install створює файл conan_toolchain.cmake і пресети, через які CMake дізнається, де лежать залежності.

CPM.cmake: залежності без окремого інструмента

CPM — скрипт на CMake, який обгортає FetchContent і додає кеш завантажень. Він не потребує встановлення: один файл CPM.cmake копіюється в репозиторій, а залежності підключаються однорядковими викликами.

cmake_minimum_required(VERSION 3.15)
project(MyApp CXX)

set(CMAKE_CXX_STANDARD 17)

# CPM.cmake лежить у папці cmake/ вашого репозиторію
include(cmake/CPM.cmake)

CPMAddPackage("gh:fmtlib/fmt#12.1.0")
CPMAddPackage("gh:nlohmann/json@3.12.0")

add_executable(MyApp main.cpp)
target_link_libraries(MyApp PRIVATE fmt::fmt nlohmann_json::nlohmann_json)

Запис gh:fmtlib/fmt#12.1.0 означає «GitHub, репозиторій fmtlib/fmt, тег 12.1.0». Це зручно для малих проєктів і прототипів. Обмеження ті самі, що й у FetchContent: код залежностей збирається разом із проєктом, тому для великих бібліотек це повільно.

Системні менеджери

apt, dnf, brew встановлюють бібліотеки для всієї системи. find_package знаходить їх так само, як і ті, що встановлені іншим шляхом:

# Ubuntu / Debian
sudo apt install libfmt-dev libspdlog-dev nlohmann-json3-dev

# macOS
brew install fmt spdlog nlohmann-json

Переваги: швидко, не потрібен додатковий інструмент. Недоліки: на різних системах різні версії бібліотек, немає списку залежностей у репозиторії проєкту, а на Windows такого менеджера немає. Для відтворюваної збірки в команді цього недостатньо.

Який інструмент обрати

Курс орієнтований на vcpkg: простий старт, найкраща інтеграція з Visual Studio, CMake та VS Code, а також підтримка Microsoft. Усі наступні лекції розбирають його детально.

Питання для самоперевірки

Резюме