Поделиться через

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

  • Статья

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

Существует два способа управления зависимостями с помощью 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-static)
  • Linux (x64-static)
  • 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-devel пакетамX-dev. В этом случае для использования разных версий библиотеки для различных проектов рекомендуется создавать отдельные экземпляры 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 для пользовательских конфигураций?

Да. Хотя 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 команды (сжатия).

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

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

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

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

  • packages,
  • buildtrees,
  • и downloads.

Флаг вvcpkg install команде --clean-after-build можно использовать для автоматического удаления временных файлов 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 Directoryies" и "Linker/General/Additional Library Directoryies" обычно пусто без интеграции с пользователем. При интеграции пустое значение означает, что дополненное значение по умолчанию, предоставленное vcpkg, переопределяется, а заголовки и библиотеки не найдены. Чтобы восстановить значение по умолчанию, задайте свойства, наследуемые от родительского элемента.

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

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

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

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

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

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

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

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

  • Per-dll vs Per-application. При независимой версии зависимостей на уровне библиотеки она призывает каждую среду сборки быть совершенно уникальной, не в состоянии воспользоваться преимуществами или внести свой вклад в прочную, хорошо проверенную экосистему. В отличие от этого, путем совместного управления версиями всех библиотек как платформы (аналогично диспетчеру системных пакетов), мы надеемся объединить тестирование и усилия по очень общим наборам версий библиотек, чтобы максимально повысить качество и стабильность экосистемы. Это также полностью разрабатывает возможность для библиотеки запрашивать версии, которые конфликтуют с выбором приложения (я хочу открыть 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, в сравнении, предназначен для получения библиотек, необходимых для создания приложения, и поможет вам реализовать любую платформу, которую вы хотите (включая Шоколадие!).