Handbuch zur Problembehandlung bei der Versionsverwaltung

Artikel
04/04/2024

Dieses Handbuch richtet sich an Benutzer, die Probleme mit der Versionsverwaltung haben.

Überprüfen der Versionsdatei für einen Port

Hinweis

Der unten beschriebene Prozess soll für Ports aus der vcpkg-Registrierung funktionieren. In unserer Registrierungsdokumentation erfahren Sie, wie die Versionsverwaltungsdatenbank in benutzerdefinierten Registrierungen implementiert wird.

So prüfen Sie die Versionsdatenbank eines bestimmten Ports:

Navigieren Sie zum Verzeichnis vcpkg/versions.
Suchen Sie den Ordner des Ports:
- Suchen Sie den Ordner, der dem ersten Buchstaben des Ports entspricht. For example, for fmt open the folder named f-.
Öffnen Sie die Portversionsdatei:
- Suchen Sie die JSON-Datei mit demselben Namen des Ports. Die Versionsdatei heißt z. B.fmtfmt.json.

Die Versionsdatei des Ports enthält eine Liste der verfügbaren Versionen mit Details wie Versionstags und dem entsprechenden Git-Strukturobjekthash. Diese Informationen werden von vcpkg benötigt, um bestimmte Portversionen abzurufen. Es stehen nur Versionen in dieser Liste zur Verfügung, die in Ihren Manifestdateien verwendet werden können.

Weitere Informationen zur Versionsverwaltung finden Sie in unserer Referenzdokumentation:

Weitere Informationen zur Verwendung eines Manifests finden Sie unter Manifest

Ursache: Anfordern einer nicht vorhandenen Version eines Pakets

Wenn eine in der Manifestdatei angegebene Version in der vcpkg-Versionsdatenbank nicht vorhanden ist, kann vcpkg die Abhängigkeit nicht beheben und eine Fehlermeldung wie folgt erzeugt:

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.

So lösen Sie das Problem:

Aktualisieren sie die Versionsdatenbank:
- Die gewünschte Version ist möglicherweise nicht in Ihrer lokalen Kopie der Versionsdatenbank enthalten. Führen Sie in diesem Fall den git pull Befehl aus, um die vcpkg-Registrierung auf den neuesten Commit zu aktualisieren.
Verfügbare Versionen überprüfen:
- Wählen Sie eine der in der Versionsdatenbank verfügbaren Versionen aus.
Manifestdatei aktualisieren:
- Bearbeiten Sie Ihre vcpkg.json Datei.
- Ändern Sie die angegebene Version in eine Version, die im vcpkg-Repository verfügbar ist. Ändern Sie z. B. von "version>=": "100.0.0" in "version>=": "10.1.1".
Ausführen der vcpkg-Installation:
- Führen Sie den vcpkg install Befehl erneut in Ihrem Terminal oder an der Eingabeaufforderung aus.

Ursache: Angeben der Versionseinschränkung in verschiedenen Schemas

Ein Versionsschemakonflikt tritt auf, wenn die in der vcpkg.json Datei für eine Abhängigkeit angegebene Version ein anderes Versionsverwaltungsschema verwendet als das Schema, das in der Basisversion des vcpkg-Repositorys verwendet wird. Dies führt zu einem Fehler, da vcpkg Versionen nicht in verschiedenen Schemas vergleichen kann.

Wenn eine deklarierte version>= Einschränkung ein anderes Versionsschema als das in der Basisplanversion verwendete verwendet, kann vcpkg nicht ermitteln, welche Version größer oder gleich dem anderen ist.

Wenn Sie also z. B. folgendes angeben:

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

vcpkg gibt die folgende Fehlermeldung aus:

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.

Lösungen:

Verwenden Sie ein kompatibles Versionsschema:
- Überprüfen Sie die Versionsdatenbank im vcpkg-Repository, versions/b-/boost-regex.json um eine Version davon boost-regex zu finden, die das gleiche Versionsverwaltungsschema wie der Basisplan verwendet.
- Aktualisieren Sie die version>= Einschränkung in Ihrer vcpkg.json Version, die ein kompatibles Schema verwendet.
Überschreiben Sie die gewünschte Version:
- Wenn Sie eine bestimmte Version von Boost-regex benötigen, die ein anderes Versionsverwaltungsschema verwendet, können Sie es in Ihrem Manifest überschreiben.
- Ändern Sie Ihren vcpkg.json Abschnitt so, dass er einen Außerkraftsetzungsbereich enthält, der die gewünschte Version angibt:
```
{
  "dependencies": [
    { "name": "boost-regex" }
  ],
  "overrides": [
    { "name": "boost-regex", "version": "1.75.0" }
  ]
}
```

Ursache: Unzureichender Commitverlauf im flachen Klon

Wenn vcpkg mit einem eingeschränkten Commitverlauf geklont wird (flacher Klon), fehlt der erforderliche Commit-Verlauf, um bestimmte Versionsbeschränkungen oder Basispläne aufzulösen. Die von vcpkg zum Abrufen bestimmter Ports verwendeten Git-Strukturobjekthashes sind nur verfügbar, wenn der vollständige Commit-Verlauf ausgecheckt ist. vcpkg erkennt, wenn es in ein flaches Repository geklont wurde, und erzeugt eine Fehlermeldung, wenn keine Portversion abgerufen werden kann.

Verwenden Sie z. B. einen vcpkg.json mit einem bestimmten Basisplan wie den folgenden:

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

Führt zu folgendem Fehler:

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

Dieser Fehler gibt an, dass der für die spezifische Version des Pakets fmt erforderliche Commit (4f8427eb0bd40da1856d4e67bde39a4fda689d72) im flachen Klon nicht verfügbar ist.

Lösungen:

Konvertieren in einen vollständigen Klon
- Die einfachste Lösung für dieses Problem besteht darin, in den vollständigen Klon zu konvertieren:
```
git fetch --unshallow
```
Verwenden von GitHub-Aktionen (Standard für flache Klonen)
- GitHub-Aktionen werden häufig standardmäßig auf flachen Klonen festgelegt. Um dies zu umgehen, können Sie den GitHub-Aktionsworkflow so ändern, dass ein vollständiger Klon ausgeführt wird. Fügen Sie den folgenden Schritt hinzu, bevor Sie vcpkg verwenden:
```
- name: Convert to Full Clone
  run: git fetch --unshallow
```

Ursache: Unerwartete Einbeziehung von Standardfeatures in transitive Abhängigkeiten

Beim Verwalten von Abhängigkeiten mit vcpkg stellen Sie möglicherweise fest, dass transitive Abhängigkeiten mit ihren Standardfeatures installiert werden, auch wenn Sie diese Features für Ihr Projekt möglicherweise nicht benötigen. Diese Situation kann zu unerwarteten Aufblähungen oder Funktionen in Ihrem endgültigen Build führen.

Szenario

Sie haben eine Abhängigkeit von der Bibliothek Y, die wiederum von der Bibliothek Xabhängt. Die Bibliothek X verfügt über Standardfeatures, einschließlich fooder Features, die Sie aus Ihrem Projekt ausschließen möchten. Ihr Manifest auf oberster Ebene für die Bibliothek Y sieht möglicherweise wie folgt aus:

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

Sie erwarten, dass dies X aufgrund der Einstellung ohne die "default-features": false Standardfeatures installiert wird. X Wird jedoch weiterhin mit dem Standardfeature fooinstalliert.

`Reason`

Die default-features Eigenschaft wird nur im Manifest der obersten Ebene berücksichtigt. Dies bedeutet, dass standardfeatures von transitiven Abhängigkeiten (wie X in diesem Szenario) weiterhin enthalten sind, es sei denn, dies ist explizit auf der obersten Ebene deaktiviert. Wenn die Bibliothek Y aufgelöst wird, vcpkg wird die "default-features": false Einstellung nicht an die transitive Abhängigkeit Xweitergegeben, was zur Installation der X Standardfeatures führt.

Lösung

Um sicherzustellen, dass transitive Abhängigkeiten wie X ohne ihre Standardfeatures installiert werden, müssen Sie sie für direkte Abhängigkeiten im Manifest der obersten Ebene heraufstufen und ihre Standardfeatures explizit deaktivieren. Ändern Sie Ihre vcpkg.json Direkteinschließung X mit "default-features": false:

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

Mit diesem Ansatz wird sichergestellt, dass sie X ohne ihre Standardfeatures installiert wird, da jetzt X eine direkte Abhängigkeit mit einer expliziten Anweisung zum Ausschließen von Standardfeatures besteht.

Ausführlichere Informationen zur Funktionsweise von Standardfeatures und deren Verwaltung finden Sie im Artikel zum Standardfeaturekonzept.

Das Problem ist hier nicht aufgeführt

Wenn Ihr Problem hier nicht aufgeführt ist, besuchen Sie unser Repository , um ein neues Problem zu erstellen.

Freigeben über