Вопросы и ответы

Что такое классический режим и режим манифеста?

Существует два способа управления зависимостями с помощью vcpkg:

1. Режим манифеста позволяет объявлять прямые зависимости, ограничения версий и используемые реестры в файле с именем vcpkg.json. Этот файл должен быть включен в репозиторий кода и может быть внесен в вашу систему управления версиями. Зависимости устанавливаются в вложенную папку с именем vcpkg_installed. Таким образом, каждый проект кода может иметь собственный набор зависимостей; ничего не установлено в системном режиме. Вы можете запустить vcpkg в режиме манифеста, запустив vcpkg install (без дополнительных аргументов), или воспользовавшись автоматической интеграцией с MSBuild и проектами CMake. Мы рекомендуем использовать манифесты для проектов в классическом режиме в большинстве случаев, так как у вас есть лучший контроль над зависимостями. Дополнительные сведения см. в нашей статье о режиме манифеста.
2. Классический режим — это более традиционный способ управления зависимостями, который включает выполнение команд vcpkg, определяющих каждую прямую зависимость для установки, изменения или удаления. Зависимости хранятся в каталоге установки vcpkg, поэтому несколько потребляющих проектов могут ссылаться на один набор зависимостей. Дополнительные сведения см. в нашей статье о классическом режиме.

Можно ли внести свой вклад в новую библиотеку?

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

Если вы хотите внести свой вклад, но не имеете в виду определенную библиотеку, ознакомьтесь со списком новых запросов на порт.

Можно ли vcpkg создать предварительно созданные двоичные пакеты? Какой двоичный формат используется vcpkg?

Да! См. командуexport файлы для экспорта в другие среды.

Кроме того, если ваша цель — сохранить двоичные файлы, созданные vcpkg install операциями для последующего повторного использования, см . функцию двоичного кэширования.

Разделы справки библиотеки обновлений?

Если вы используете манифест (vcpkg.json файл) для управления зависимостями, необходимо обновить этот файл. Дополнительные сведения см. в справочной документации о версионировании.

Если вы используете vcpkg в классическом режиме (для выполнения команд управления пакетами, без файла манифеста), см. документацию по командамvcpkg update Эта команда перечисляет все пакеты, которые не синхронизируются с текущими портфайлами. Затем необходимо выполнить vcpkg upgrade команду , чтобы подтвердить изменения.

Как мне получить больше библиотек?

Список библиотек перечисляется из ports\ каталога. По задумке, вы можете добавлять и удалять библиотеки из этого каталога, как считаете нужным для себя или вашей компании — см. наши примеры по упаковке ZIP-файлов и репозиториев GitHub.

Мы рекомендуем клонировать непосредственно из GitHub и использовать git pull для обновления списка портфайлов.

Можно ли создать частную библиотеку с помощью этого средства?

Да. Следуйте примеру нашей упаковки, чтобы создать собственный порт, а также ознакомьтесь с документацией по оверлейным портам и реестрам, чтобы узнать, как управлять частными портами.

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

Можно ли использовать предварительно созданную частную библиотеку с этим средством?

Да. Для portfile.cmake библиотеки в основном это скрипт, который помещает заголовки и двоичные файлы в правильное расположение в ${CURRENT_PACKAGES_DIR}файле, поэтому для извлечения предварительно созданных двоичных файлов можно написать портфайл, который напрямую скачивает и упорядочивает файлы.

Чтобы посмотреть пример, взгляните на ports\opengl\portfile.cmake, где просто копируются файлы из пакета SDK для Windows.

На какие платформы я могу нацелить в vcpkg?

Встроенные, проверенные триплеты непрерывной интеграции:

• Рабочий стол Windows (x86, x64, x64-static, arm64)
• универсальная платформа Windows (x64 и arm64)
• Mac OS X (x64-статический)
• Linux (x64-статический)
• Android (x64, arm64, arm-neon)

Эти целевые объекты тестируются более строго для обеспечения совместимости с каждым выпуском vcpkg. Тем не менее, у нас доступно гораздо большее количество сообщественных триплетов с более широким набором платформ и архитектур, таких как iOS, MinGW, WebAssembly, FreeBSD и OpenBSD.

Вы также можете определить собственные тройки в зависимости от ваших нужд. vcpkg очень настраиваемый.

Дополнительные сведения см vcpkg help triplet . в текущем списке и ознакомьтесь с нашей документацией по триплетам.

Работает ли vcpkg в Linux или OS X?

Да! Мы постоянно тестируем ОС X и Ubuntu 22.04, однако мы знаем, что пользователи были успешными с Arch, Fedora и FreeBSD. Если у вас возникли проблемы с любимым дистрибутивом Linux, сообщите нам о проблеме, и мы будем рады помочь!

Разделы справки обновление vcpkg?

Выполните выполнение git pull , чтобы получить последние источники, а затем запустите bootstrap-vcpkg.bat (Windows) или ./bootstrap-vcpkg.sh (Unix) для обновления vcpkg. Или, если вы используете копию vcpkg, которая поставляется с Visual Studio, просто обновите версию Visual Studio из Visual Studio Installer.

Как использовать разные версии библиотеки на одном компьютере?

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

Однако если вы используете классический режим вместо этого, в одном экземпляре vcpkg (например, один набор installed\, packages\ports\ и т. д.), вы можете установить только одну версию библиотеки (в противном случае заголовки будут конфликтуть друг с другом!). Для тех, кто имеет опыт работы с системными диспетчерами пакетов, пакеты в vcpkg соответствуют пакетам X-dev или X-devel. В этом случае для использования разных версий библиотеки для различных проектов рекомендуется создавать отдельные экземпляры vcpkg и использовать механизмы интеграции с проектом. Версии каждой библиотеки задаются файлами ports\, поэтому они легко управляются с помощью стандартных git команд. Это упрощает откат всего набора библиотек к согласованному набору старых версий, которые совместимы друг с другом. Если вам нужно закрепить определенную библиотеку вперед, это так же просто, как проверить соответствующую версию ports\<package>\. Если приложение очень чувствительно к версиям библиотек, рекомендуется проверить определенный набор портов, необходимых для управления версиями, вместе с источниками проекта и с помощью --vcpkg-root параметра перенаправления рабочего каталога vcpkg.exe.

Как vcpkg защищает мою конфиденциальность?

Ознакомьтесь с документом о конфиденциальности, чтобы получить всю необходимую информацию.

Можно ли использовать собственный файл цепочки инструментов CMake с файлом цепочки инструментов vcpkg?

Да. Если у вас уже есть файл цепочки инструментов CMake, вам потребуется включить наш файл цепочки инструментов в конце вашего приложения. Это должно быть так же просто, как директива include(<vcpkg_root>\scripts\buildsystems\vcpkg.cmake) . В качестве альтернативы вы можете скопировать содержимое нашего scripts\buildsystems\vcpkg.cmake в конец существующего файла вашей цепочки инструментов.

Можно ли использовать собственные или определенные флаги для перестроения библиотек?

Да. Пользовательские триплеты можно использовать для изменения флагов компиляции с помощью переменных VCPKG_C_FLAGS и VCPKG_CXX_FLAGS.

Вы также можете настроить флаги для каждого порта по отдельности. Рассмотрим пример.

if (PORT MATCHES "my-port")
  set(VCPKG_CXX_FLAGS "-D_CRT_SECURE_NO_WARNINGS")
  set(VCPKG_C_FLAGS "-D_CRT_SECURE_NO_WARNINGS")
endif()

Можно ли получить интеграцию vcpkg для пользовательских конфигураций?

Да. Хотя vcpkg будет создавать стандартные конфигурации "Выпуск" и "Отладка" при создании библиотеки, вы можете получить поддержку интеграции для пользовательских конфигураций проектов в дополнение к стандартным конфигурациям проекта.

Во-первых, vcpkg автоматически предполагает любую настраиваемую конфигурацию, начиная с "Выпуск" (resp. "Отладка") в качестве конфигурации, совместимой со стандартной конфигурацией "Выпуск" (resp. Debug) и будет действовать соответствующим образом.

Для других конфигураций необходимо переопределить макрос MSBuild $(VcpkgConfiguration) в файле проекта (.vcxproj), чтобы объявить совместимость между конфигурацией и целевой стандартной конфигурацией. К сожалению, из-за последовательного характера MSBuild вам необходимо добавить эти настройки гораздо выше в файл vcxproj, чтобы они были объявлены до того, как интеграция vcpkg будет загружена и выполнена. Рекомендуется добавить макрос $(VcpkgConfiguration) в группу свойств "Globals".

Например, можно добавить поддержку конфигурации MyRelease, добавив в файл проекта:

<PropertyGroup Label="Globals">
  ...
  <VcpkgConfiguration Condition="'$(Configuration)' == 'MyRelease'">Release</VcpkgConfiguration>
</PropertyGroup>

Конечно, это создаст только жизнеспособные двоичные файлы, если настраиваемая конфигурация совместима с целевой конфигурацией (например, они должны связаться с одной библиотекой среды выполнения).

Не удается использовать интеграцию на уровне пользователей. Можно ли использовать интеграцию для каждого проекта?

Да. Пакет NuGet, подходящий для использования в каждом проекте, можно создать с помощью команды vcpkg integrate project (легкой связки) или команды vcpkg export --nuget (запакованный).

Механизм более низкого уровня для достижения того же, что и пакет NuGet, осуществляется через файл vcpkg integrate project. Все, что вам нужно, — импортировать его в файл .vcxproj, заменив <vcpkg_root> путь, по которому вы установили vcpkg:

<Import Project="<vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets" />

Как удалить временные файлы?

Если вы заботитесь только об установленных пакетах, безопасно удалить следующие каталоги в корневой папке vcpkg:

• packages,
• buildtrees,
• и downloads.

Вы можете использовать флаг --clean-after-build в вашей команде vcpkg install, чтобы vcpkg автоматически удалял временные файлы после завершения сборки.

vcpkg также использует другие временные расположения, внешние к корневой папке vcpkg. Файлы интеграции Visual Studio, двоичный кэш по умолчанию и кэш реестров; находятся в следующем пути в зависимости от операционной системы:

В Windows:

• %LocalAppData%/vcpkg

В Linux или macOS:

• $XDG_CACHE_HOME/vcpkg
• ~/.cache/vcpkg (только если XDG_CACHE_HOME не определено)

Если вы настроили локальные двоичные файлы или кэши ресурсов, может потребоваться периодически очистить их по мере необходимости.

Как CMake используется внутри vcpkg?

vcpkg внутренне использует CMake в качестве языка скриптов сборки. Это связано с тем, что CMake уже является чрезвычайно распространенной системой сборки для кроссплатформенных библиотек с открытым исходным кодом и становится всё более популярным в целом для проектов на C++. Легко получить на платформе Windows, не требует установки на уровне системы, а удобно для незнакомых пользователей.

Поддерживает ли vcpkg скачивание скомпилированных двоичных файлов с общедоступного или частного сервера?

Рекомендуется создавать библиотеки один раз с предпочитаемыми конфигурациями сборки и использовать функцию двоичного кэширования для повторного использования двоичных файлов без необходимости повторной сборки каждый раз. Это полезно при работе с командным проектом или при создании как локально, так и в среде непрерывной интеграции на нескольких компьютерах, контейнерах, виртуальных машинах и т. д.

Какие наборы инструментов MSVC поддерживаются?

Мы поддерживаем Visual Studio 2015 с обновлением 3 и выше.

Почему Visual Studio не использует мои библиотеки с включенной интеграцией на уровне пользователей?

Включение интеграции на уровне пользователя (vcpkg integrate install) изменяет значение по умолчанию для некоторых свойств проекта. В частности, "C/C++/General/Additional Include Directories" и "Linker/General/Additional Library Directories" обычно пусты без интеграции на уровне пользователя. При интеграции пустое значение означает, что дополненное значение по умолчанию, предоставленное vcpkg, переопределяется, и заголовки/библиотеки не будут найдены. Чтобы восстановить значение по умолчанию, задайте свойства, наследуемые от родительского элемента.

Почему бы не NuGet?

NuGet — это диспетчер пакетов для библиотек .NET с сильной зависимостью от MSBuild. Он не соответствует конкретным потребностям клиентов Native C++ по крайней мере тремя способами.

• Варианты компиляции. При столь большом количестве возможных сочетаний параметров компиляции задача предоставления действительно полного набора параметров по сути невозможна. Кроме того, размер загрузки для достаточно полных двоичных пакетов становится огромным. Это требует разделить результаты на несколько пакетов, но затем поиск становится очень сложным.

• Двоичный файл и источник. Очень тесно связан с первой точкой, NuGet разработан с нуля, чтобы обеспечить относительно небольшие предварительно созданные двоичные файлы. В связи с характером машинного кода разработчикам необходимо иметь доступ к исходному коду, чтобы обеспечить совместимость ABI, производительность, целостность и отладку.

• По библиотеке и по приложению. NuGet очень ориентирован на проект. Это хорошо работает на управляемых языках с естественно стабильными ABI, так как базовые библиотеки могут продолжать развиваться, не нарушая те, что находятся выше. Однако на собственных языках, где ABI гораздо более хрупкий, единственная надежная стратегия заключается в явной сборке каждой библиотеки в соответствии с точными зависимостями, которые будут включены в окончательное приложение. Это трудно обеспечить в NuGet и приводит к сильно несвязанной экосистеме с независимыми версиями.

Почему не Конан?

Conan.io — это общедоступный федеративный, ориентированный на проект, кроссплатформенный диспетчер пакетов C++, написанный на python. Основные различия:

• Общедоступная федерация против частной федерации. Conan полагается на отдельных лиц, публикующих независимые копии каждого пакета. Мы считаем, что этот подход способствует появлению большого числа пакетов, каждый из которых имеет свои недостатки. Мы считаем, что это пустая трата времени пользователя — просматривать список из более чем 20 общедоступных пакетов для Boost 1.56, чтобы определить несколько, которые подойдут для их конкретной ситуации. В отличие от этого, мы считаем, что должна быть одна, совместно поддерживаемая версия, которая работает для подавляющего большинства случаев и позволяет пользователям свободно взломать свои частные версии. Мы считаем, что это приведет к набору высококачественных пакетов, которые сильно тестируются друг с другом и формируют фантастическую базу для любых частных изменений, которые вам нужны.

• По библиотеке и по приложению. При независимой версии зависимостей на уровне библиотеки она призывает каждую среду сборки быть совершенно уникальной, не в состоянии воспользоваться преимуществами или внести свой вклад в прочную, хорошо проверенную экосистему. В отличие от этого, путем совместного управления версиями всех библиотек как платформы (аналогично диспетчеру системных пакетов), мы надеемся объединить тестирование и усилия по очень общим наборам версий библиотек, чтобы максимально повысить качество и стабильность экосистемы. Это также полностью разрабатывает возможность для библиотеки запрашивать версии, которые конфликтуют с выбором приложения (я хочу открыть z и повысить X, но X только утверждения для работы с opensl Y).

• Кроссплатформенная и одноплатформенная. Хотя размещение на многих платформах является отличной северной звездой, мы считаем, что уровень системной интеграции и стабильности, предоставляемой apt-get, yum и homebrew, хорошо стоит обмениваться apt-get install libboost-all-dev с brew install boost автоматизированными скриптами. Мы решили сделать нашу систему как можно проще интегрировать в мир с этими очень успешными системными менеджерами - еще одна линия для vcpkg install boost - вместо того, чтобы попытаться заменить их, где они уже так успешны и хорошо любимы.

• C++/CMake и Python. Хотя Python является отличным языком, любимым многими, мы считаем, что прозрачность и знакомство являются наиболее важными факторами при выборе инструмента как важного для рабочего процесса в качестве диспетчера пакетов. Следовательно, мы решили сделать языки реализации как можно более универсальными: C++ должен использоваться в диспетчере пакетов C++ для программистов C++. Вам не нужно учиться другому языку программирования только для понимания диспетчера пакетов.

Почему бы не Шоколадный?

Шоколадный — отличная система для управления приложениями. Однако в настоящее время он не предназначен для получения распространяемых ресурсов разработчика и помогает выполнять отладку. Vcpkg, в сравнении, предназначен для получения библиотек, необходимых для создания приложения, и поможет вам реализовать любую платформу, которую вы хотите (включая Шоколадие!).