CONTROL-Dateien

Die CONTROL Datei enthält Metadaten zum Port. Die Syntax basiert auf dem Debian-Formatcontrol, obwohl wir nur die Teilmenge der hier dokumentierten Felder unterstützen.

Bei Feldnamen wird die Groß-/Kleinschreibung beachtet und die Zeile ohne führende Leerzeichen gestartet. Absätze werden durch eine oder mehrere leere Zeilen getrennt.

Quellabsatz

Der erste Absatz in einer CONTROL Datei ist der Quellabsatz. Er muss ein Source, Versionund Description ein Feld aufweisen. Die vollständige Gruppe von Feldern ist unten dokumentiert.

Beispiele

Source: ace
Version: 6.5.5
Description: The ADAPTIVE Communication Environment

Source: vtk
Version: 8.2.0
Port-Version: 2
Description: Software system for 3D computer graphics, image processing, and visualization
Build-Depends: zlib, libpng, tiff, libxml2, jsoncpp, glew, freetype, expat, hdf5, libjpeg-turbo, proj4, lz4, libtheora, atlmfc (windows), eigen3, double-conversion, pugixml, libharu, sqlite3, netcdf-c

Erkannte Felder

Quelle

Der Name des Ports.

Beachten Sie beim Hinzufügen neuer Ports, dass der Name möglicherweise mit anderen Projekten in Konflikt steht, die nicht Teil von vcpkg sind. Beispielsweise json tritt ein Konflikt mit zu vielen anderen Projekten auf, sodass Sie dem Namen einen Bereich hinzufügen sollten, z taocpp-json . B. um sie eindeutig zu machen. Überprüfen Sie, ob es keine Konflikte in einer Suchmaschine sowie in anderen Paketsammlungen gibt.

Paketsammlungen, die auf Konflikte überprüft werden sollen:

• Repology
• Debian-Pakete

Version

Die Bibliotheksversion.

Dieses Feld ist eine alphanumerische Zeichenfolge, die auch ., oder _-. Es wird kein Versuch unternommen, Versionen zu bestellen; Alle Versionen werden als Bitzeichenfolgen behandelt und nur für Gleichheit ausgewertet.

Für getaggte Veröffentlichungsports folgen wir der folgenden Konvention:

1. Wenn der Port einem Schema folgt, wie va.b.c, entfernen wir die führende v. In diesem Fall wird a.b.ces .
2. Wenn der Port seinen eigenen Namen in der Version wie curl-7_65_1folgt enthält, entfernen wir den führenden Namen: 7_65_1

Für Roll-Release-Ports verwenden wir das Datum, an dem der Commit von Ihnen aufgerufen wurde, formatiert als YYYY-MM-DD. Ein weiterer Weg: Wenn jemand einen Zeitautomaten hatte und zu diesem Datum ging, würde er diesen Commit als neuestes Master-Shape sehen.

Angenommen, dies liegt vor:

1. Der letzte Commit wurde am 2019-04-19
2. Die aktuelle Versionszeichenfolge ist 2019-02-14-1
3. Das heutige Datum ist 2019-06-01.

Wenn Sie dann die Quellversion heute aktualisieren, sollten Sie die Version 2019-06-01zuweisen.

Port-Version

Die Version des Ports.

Dieses Feld ist eine nicht negative ganze Zahl. Sie ermöglicht es einer, die Portdatei separat von der Version der zugrunde liegenden Bibliothek zu versionieren; Wenn Sie eine Änderung an einem Port vornehmen, ohne die zugrunde liegende Version der Bibliothek zu ändern, sollten Sie dieses Feld um ein Feld erhöhen (beginnend bei 0, das keinem Port-Version Feld entspricht). Wenn die Version der zugrunde liegenden Bibliothek aktualisiert wird, sollte dieses Feld wieder auf 0 (d. h. das Port-Version Feld löschen) zurückgesetzt werden.

Beispiele

Version: 1.0.5
Port-Version: 2

Version: 2019-03-21

Beschreibung

Eine Beschreibung der Bibliothek.

In der Konvention ist die erste Zeile der Beschreibung eine Zusammenfassung der Bibliothek. Eine optionale detaillierte Beschreibung folgt. Die detaillierte Beschreibung kann mehrere Zeilen sein, beginnend mit Leerzeichen.

Beispiele

Description: C++ header-only JSON library

Description: Mosquitto is an open source message broker that implements the MQ Telemetry Transport protocol versions 3.1 and 3.1.1.
  MQTT provides a lightweight method of carrying out messaging using a publish/subscribe model. This makes it suitable for "machine
  to machine" messaging such as with low power sensors or mobile devices such as phones, embedded computers or microcontrollers like the Arduino.

Homepage

Die URL der Homepage für die Bibliothek, in der ein Benutzer zusätzliche Dokumentation oder den ursprünglichen Quellcode finden kann.

Beispiel:

Homepage: https://github.com/Microsoft/vcpkg

Build-abhängig

Kommagetrennte Liste der vcpkg-Ports, von der die Bibliothek abhängig ist.

vcpkg unterscheidet nicht zwischen buildgeschützten Abhängigkeiten und Laufzeitabhängigkeiten. Die vollständige Liste der Abhängigkeiten, die für die erfolgreiche Verwendung der Bibliothek erforderlich sind, sollte angegeben werden.

Beispiel: Websocketpp ist nur eine Kopfzeilenbibliothek und erfordert daher zur Installation keine Abhängigkeiten. Nachgeschaltete Benutzer benötigen jedoch eine Verstärkung und öffnet sie, um die Bibliothek zu nutzen. Daher werden websocketpp-Listen als Abhängigkeiten herauf- und geöffnet.

Wenn der Port von optionalen Features einer anderen Bibliothek abhängig ist, können diese mithilfe der portname[featurelist] Syntax angegeben werden. Wenn für den Port keine Features aus der Abhängigkeit erforderlich sind, sollte dies als portname[core]angegeben werden.

Abhängigkeiten können basierend auf dem Ziel-Triplet gefiltert werden, um unterschiedliche Anforderungen zu unterstützen. Diese Filter verwenden dieselbe Syntax wie das feld "Supports" unten und sind in Klammern nach portname und Featureliste eingeschlossen.

Beispiel

Build-Depends: rapidjson, curl[core,openssl] (!windows), curl[core,winssl] (windows)

Standardfeatures

Durch Trennzeichen getrennte Liste optionaler Portfeatures, die standardmäßig installiert werden sollen.

Dieses Feld ist optional.

Beispiel

Default-Features: dynamodb, s3, kinesis

Unterstützt

Ausdruck, der "true" auswertet, wenn der Port für ein Triplet erfolgreich erstellt werden soll.

Derzeit wird dieses Feld nur in den CI-Tests verwendet, um Ports zu überspringen. In Zukunft soll dieser Mechanismus Benutzer im Voraus warnen, dass eine bestimmte Installationsstruktur nicht erfolgreich sein wird. Daher sollte dieses Feld optimistisch verwendet werden; in Fällen, in denen erwartet wird, dass ein Port 10 % der Zeit erfolgreich ist, sollte er weiterhin als "unterstützt" gekennzeichnet werden.

Siehe Plattformausdrücke in der vcpkg.json Manifestdokumentation für die Liste der unterstützten Bezeichner.

Beispiel

Supports: !(uwp|arm)

Featureabsätze

In den CONTROL Dateien können mehrere optionale Features angegeben werden. Es muss über ein Feld und Description ein Feature Feld verfügen. Es kann optional ein Build-Depends Feld enthalten. Sie muss von anderen Absätzen durch eine oder mehrere leere Zeilen getrennt werden.

Beispiel

Source: vtk
Version: 8.2.0-2
Description: Software system for 3D computer graphics, image processing, and visualization
Build-Depends: zlib, libpng, tiff, libxml2, jsoncpp, glew, freetype, expat, hdf5, libjpeg-turbo, proj4, lz4, libtheora, atlmfc (windows), eigen3, double-conversion, pugixml, libharu, sqlite3, netcdf-c

Feature: openvr
Description: OpenVR functionality for VTK
Build-Depends: sdl2, openvr

Feature: qt
Description: Qt functionality for VTK
Build-Depends: qt5

Feature: mpi
Description: MPI functionality for VTK
Build-Depends: mpi, hdf5[parallel]

Feature: python
Description: Python functionality for VTK
Build-Depends: python3

Erkannte Felder

Funktion

Der Name der Funktion.

Beschreibung

Eine Beschreibung des Features mit derselben Syntax wie das Portfeld Description .

Build-abhängig

Die Liste der Abhängigkeiten, die zum Erstellen und Verwenden dieses Features erforderlich sind.

Bei der Installation werden die Abhängigkeiten aller ausgewählten Features kombiniert, um die vollständige Abhängigkeitsliste für den Build zu erstellen. Dieses Feld folgt der gleichen Syntax wie Build-Depends im Quellabsatz.