CONTROL-Dateien
Warnung
CONTROL
Dateien sind veraltet und werden nur aus Gründen der Abwärtskompatibilität mit früheren Versionen von vcpkg beibehalten. Verwenden Sie vcpkg.json Manifestdateien für jeden neu erstellten Port.
Wird ./vcpkg format-manifest path/to/CONTROL
verwendet, um eine vorhandene CONTROL
Datei in eine vcpkg.json
Datei zu konvertieren.
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
, Version
und 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:
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:
- Wenn der Port einem Schema folgt, wie
va.b.c
, entfernen wir die führendev
. In diesem Fall wirda.b.c
es . - Wenn der Port seinen eigenen Namen in der Version wie
curl-7_65_1
folgt 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:
- Der letzte Commit wurde am 2019-04-19
- Die aktuelle Versionszeichenfolge ist
2019-02-14-1
- Das heutige Datum ist 2019-06-01.
Wenn Sie dann die Quellversion heute aktualisieren, sollten Sie die Version 2019-06-01
zuweisen.
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.