vcpkg — менеджер пакетов, который Microsoft создала для себя и отдала всем

Знаете, что объединяет большинство C++ проектов? Правильно — мучения с зависимостями. Вы хотите просто подключить библиотеку для работы с JSON, а в итоге проводите полдня, разбираясь с путями, версиями компиляторов и несовместимостью операционных систем. Microsoft это надоело — и они сделали vcpkg.

Забавно, но изначально это был внутренний инструмент. В 2016 году команде Visual Studio нужно было что-то, что помогло бы разработчикам безболезненно мигрировать проекты на новые версии студии. Получилось настолько хорошо, что инструмент выкатили в open source. И вот уже почти десять лет vcpkg спокойно решает проблемы, которые в C++ считались неизбежным злом.

Что это вообще такое?

vcpkg — это пакетный менеджер. Но не в стиле npm или pip, где всё работает из коробки, потому что экосистема изначально проектировалась с мыслью о зависимостях. Здесь другой уровень сложности: кроссплатформенность, разные компиляторы, статическая и динамическая линковка, архитектуры процессоров. C++ — это минное поле, где каждый шаг может забрать у вас пол дня на решение неожиданной ошибки компиляции.

vcpkg пытается навести в этом порядок. Он берёт исходники библиотек (обычно из официальных источников), собирает их под вашу конкретную конфигурацию и интегрирует в проект. Звучит просто, но дьявол в деталях — и именно эти детали vcpkg обрабатывает за вас.

Написан инструмент, кстати, на самом C++ с использованием CMake. Это значит, что создатели прочувствовали боль на собственной шкуре и решали реальные проблемы, а не абстрактные.

Как это работает на практике

Представьте: вам нужна библиотека форматирования {fmt}. В классическом подходе вы идёте на GitHub, клонируете репозиторий, читаете документацию по сборке, настраиваете CMake, молитесь, чтобы всё собралось… А с vcpkg это выглядит так:

vcpkg install fmt

Всё. Библиотека установлена, пути настроены, можно подключать и использовать. Работает на Windows, macOS и Linux одинаково.

Более продвинутый вариант — создать манифест для проекта:

vcpkg new --application
vcpkg add port fmt

Теперь зависимости описаны декларативно, и любой, кто склонирует ваш проект, получит ровно те же версии библиотек. Это как package.json в Node.js, только для C++.

Интеграция с системами сборки тоже продумана. CMake поддерживается нативно через toolchain файл. MSBuild работает автоматически в Visual Studio. Но даже если вы используете что-то экзотическое — Make, Ninja, собственные скрипты — vcpkg не встанет поперёк горла. Он просто даёт вам библиотеки в нужном месте, а дальше делайте что хотите.

Что выделяет vcpkg среди конкурентов

Менеджеры пакетов для C++ есть разные — Conan, Hunter, cpm. Но vcpkg занимает особую нишу благодаря нескольким вещам.

Во-первых, огромный каталог библиотек. На момент написания там тысячи пакетов, от мелких утилит до монстров вроде Boost или OpenCV. Причём в Microsoft не просто собирают чужой код — они активно тестируют совместимость, следят за обновлениями, исправляют баги в портах.

Во-вторых, бинарное кэширование. Собирать тот же Boost из исходников — это часы ожидания. vcpkg может сохранять готовые бинарники и переиспользовать их между проектами или даже машинами в команде. Настраивается через asset cache, работает с Azure Artifacts, GitHub Packages или любым файловым хранилищем.

В-третьих — и это неожиданно важно — офлайн-режим. Для корпоративной разработки, где сервера за файрволами и нельзя просто скачать что-то из интернета, это спасение. Вы заранее наполняете кэш, а потом работаете изолированно.

Есть ещё контроль версий через vcpkg.json. Можно зафиксировать точные версии библиотек, чтобы проект через год собирался так же, как сегодня. Это решает классическую проблему C++: “у меня работало, клонировал на другую машину — сломалось”.

Подводные камни есть?

Конечно есть. Идеального инструмента не бывает, особенно в экосистеме C++.

Скорость сборки. Если библиотеки нет в кэше, vcpkg будет собирать её из исходников. Для больших проектов это медленно. Бинарное кэширование помогает, но его нужно настроить.

Кастомизация библиотек. Многие C++ библиотеки имеют десятки опций сборки (включить/выключить фичи, выбрать бэкенд и т.д.). vcpkg поддерживает features, но не всегда покрывает все возможные комбинации. Иногда приходится писать свой порт или патчить существующий.

Экосистемная зрелость. Да, vcpkg активно развивается, но он моложе того же Conan. Некоторые сценарии (например, работа с проприетарными библиотеками или сложная кастомизация toolchain) могут потребовать дополнительных телодвижений.

И да, телеметрия. Microsoft собирает анонимные данные об использовании. Её можно отключить флагом --disable-metrics или переменной окружения, но кому-то сам факт может не понравиться.

Кому это реально нужно?

Если вы пишете на C++ что-то посерьёзнее “hello world”, vcpkg стоит попробовать. Особенно полезен он в случаях, если:

У вас кроссплатформенный проект, и вы устали синхронизировать зависимости между Windows, Linux и macOS.
В команде несколько человек, и “у меня не собирается” звучит слишком часто.
Вы работаете в корпорации с ограничениями доступа к интернету.
Хотите воспроизводимые сборки без танцев с бубном.

Для учебных проектов или быстрых экспериментов vcpkg тоже отлично подходит — просто vcpkg install и вперёд, без копания в документации каждой библиотеки.

В сухом остатке

vcpkg — это попытка привнести в C++ удобство, которое в других языках давно считается нормой. Полностью проблему зависимостей он не решает, но делает жизнь заметно проще. Microsoft вложила в проект силы, открыла код, построила коммьюнити — и теперь это стандарт де-факто для многих команд. Инструмент не идеален, но работает. А для C++ экосистемы это уже большое достижение.