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


Руководство по устранению неполадок с версиями

Это руководство предназначено для пользователей с проблемами с управление версиями.

Проверка файла версии для порта

Примечание.

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

Чтобы проверить базу данных версий определенного порта, выполните следующие действия.

  1. Перейдите к каталогу vcpkg/versions.
  2. Найдите папку порта:
    • Найдите папку, соответствующую первой букве порта. Например, для fmt открытия папки с именем f-.
  3. Откройте файл версии портов:
    • Найдите JSON-файл с тем же именем порта. Например, fmt файл версий называется fmt.json.

Файл версии порта содержит список доступных версий с такими сведениями, как теги версий и соответствующий хэш дерева дерева Git. Эти сведения требуются vcpkg для получения определенных версий портов. Доступны только версии, содержащиеся в этом списке, в файлах манифеста.

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

Дополнительные сведения об использовании манифеста см. в разделе "Манифест"

Причина. Запрос несуществующей версии пакета

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

error: no version database entry for fmt at 100.0.0
Available versions:
  10.1.1
  10.1.0
  10.0.0
  9.1.0#1
  9.1.0
  9.0.0
  8.1.1#2
  8.1.1#1
  ...
See `vcpkg help versioning` or https://learn.microsoft.com/vcpkg/users/versioning for more information.

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

  1. Обновите базу данных версий:
    • Нужная версия может не находиться в локальной копии базы данных версий. В этом случае выполните git pull команду, чтобы обновить реестр vcpkg до последней фиксации.
  2. Проверьте доступные версии:
    • Выберите одну из версий, доступных в базе данных версий.
  3. Обновление файла манифеста:
    • Измените vcpkg.json файл.
    • Измените указанную версию на ту, которая доступна в репозитории vcpkg. Например, измените значение "version=": "100.0.0" на "version>>=": "10.1.1".
  4. Выполните установку vcpkg:
    • vcpkg install Повторите команду в терминале или командной строке.

Причина. Указание ограничения версии в разных схемах

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

Если объявленное version>= ограничение использует другую схему версий, отличную от используемой в базовой версии, vcpkg не может определить, какая версия больше или равна другой.

Например, если будет указано:

{
  "dependencies": [
    {
      "name": "boost-regex",
      "version>=": "1.75.0"
    }
  ]
}

Vcpkg выводит следующее сообщение об ошибке:

error: version conflict on boost-regex:x64-windows:  required 1.75.0, which cannot be compared with the baseline version 1.83.0.

The versions have incomparable schemes:
  boost-regex@1.83.0 has scheme relaxed
  boost-regex@1.75.0 has scheme string

This can be resolved by adding an explicit override to the preferred version. For example:

  "overrides": [
    { "name": "boost-regex", "version": "1.83.0" }
  ]

See `vcpkg help versioning` or https://learn.microsoft.com/vcpkg/users/versioning for more information.

Способы устранения

  1. Используйте совместимую схему версий:
    • Проверьте базу данных версии в репозитории versions/b-/boost-regex.json vcpkg, чтобы найти версию, которая использует ту же схему управления версиями boost-regex , что и базовая.
    • version>= Обновите ограничение в vcpkg.json вашей версии, которая использует совместимую схему.
  2. Переопределите нужную версию:
    • Если вам нужна определенная версия boost-regex, использующая другую схему управления версиями, ее можно переопределить в манифесте.
    • vcpkg.json Измените раздел переопределения, указав нужную версию:
    {
      "dependencies": [
        { "name": "boost-regex" }
      ],
      "overrides": [
        { "name": "boost-regex", "version": "1.75.0" }
      ]
    }
    

Причина: неадекватная история фиксации в неглубоком клоне

Если vcpkg клонируется с ограниченным журналом фиксации (неглубокий клон), он не имеет необходимой истории фиксации для разрешения определенных ограничений версий или базовых показателей. Хэши дерева Git, используемые vcpkg для получения определенных версий портов, доступны только в том случае, если полная история фиксации проверка отключена. Vcpkg обнаруживает, когда он был клонирован в неглубокий репозиторий и выдает сообщение об ошибке, когда не удается получить версию порта.

Например, использование vcpkg.json определенного базового плана, как показано ниже:

{
  "dependencies": [
    {
      "name": "fmt"
    }
  ],
  "overrides": [
    {
      "name": "fmt",
      "version": "7.1.3#1"
    }
  ],
  "builtin-baseline": "bb588985e37484d543fc849d0d79434e0d45bb3c"
}

Приведет к следующей ошибке:

error: failed to execute: "C:\Program Files\Git\cmd\git.exe" "--git-dir=C:\dev\demo\vcpkg\.git" "--work-tree=C:\dev\demo\vcpkg\buildtrees\versioning_\versions\fmt\4f8427eb0bd40da1856d4e67bde39a4fda689d72_26648.tmp" -c core.autocrlf=false read-tree -m -u 4f8427eb0bd40da1856d4e67bde39a4fda689d72
vcpkg was cloned as a shallow repository in: C:\dev\demo\vcpkg\.git
Try again with a full vcpkg clone.
error: git failed with exit code: (128).
fatal: failed to unpack tree object 4f8427eb0bd40da1856d4e67bde39a4fda689d72
note: while checking out port fmt with git tree 4f8427eb0bd40da1856d4e67bde39a4fda689d72

Эта ошибка означает, что фиксация (4f8427eb0bd40da1856d4e67bde39a4fda689d72) необходимая для конкретной версии пакета fmt недоступна в неглубоком клоне.

Способы устранения

  1. Преобразование в полный клон

    • Самым простым решением этой проблемы является преобразование в полный клон:
    git fetch --unshallow
    
  2. Использование GitHub Actions (по умолчанию мелкие клоны)

    • Действия GitHub часто по умолчанию используются для мелких клонов. Чтобы обойти эту проблему, можно изменить рабочий процесс GitHub Actions для выполнения полного клона. Добавьте следующий шаг перед использованием vcpkg:
    - name: Convert to Full Clone
      run: git fetch --unshallow
    

Причина: неожиданное включение функций по умолчанию в транзитивных зависимостях

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

Сценарий

У вас есть зависимость от библиотеки Y, которая, в свою очередь, зависит от библиотеки X. Библиотека X имеет функции по умолчанию, в том числе foo, которые необходимо исключить из проекта. Манифест верхнего уровня для библиотеки Y может выглядеть примерно так:

{
  "name": "my-project",
  "dependencies": [
    {
      "name": "Y",
      "features": ["featureB"],
      "default-features": false
    }
  ]
}

Ожидается, что X он будет установлен без компонентов по умолчанию из-за "default-features": false параметра. X Однако по-прежнему устанавливается с функцией fooпо умолчанию.

Причина

Свойство default-features считается только в манифесте верхнего уровня. Это означает, что функции транзитивных зависимостей по умолчанию (например X , в этом сценарии) по-прежнему включаются, если явно не отключены на верхнем уровне. При разрешении библиотеки Y параметр не распространяется "default-features": false на транзитивную зависимостьX, что приводит к установке X компонентов по умолчанию. vcpkg

Разрешение

Чтобы обеспечить установку транзитных зависимостей X без компонентов по умолчанию, необходимо повысить их уровень до прямых зависимостей в манифесте верхнего уровня и явно отключить их функции по умолчанию. vcpkg.json Измените значение, чтобы включить X его напрямую с "default-features": falseпомощью:

{
  "name": "my-project",
  "dependencies": [
    {
      "name": "Y",
      "features": ["featureB"]
    },
    {
      "name": "X",
      "default-features": false
    }
  ]
}

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

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

Проблема не указана здесь

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