File CONTROL

Il CONTROL file contiene metadati sulla porta. La sintassi è basata sul formato Debiancontrol, anche se è supportato solo il subset di campi documentati qui.

I nomi dei campi fanno distinzione tra maiuscole e minuscole e iniziano la riga senza spazi vuoti iniziali. I paragrafi sono separati da una o più righe vuote.

Paragrafo di origine

Il primo paragrafo di un CONTROL file è il paragrafo Source. Deve avere un Sourcecampo , Versione Description . Il set completo di campi è documentato di seguito.

Esempi

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

Campi riconosciuti

Origine

Nome della porta.

Quando si aggiungono nuove porte, tenere presente che il nome può essere in conflitto con altri progetti che non fanno parte di vcpkg. Ad esempio, è in conflitto con troppi altri progetti, quindi è necessario aggiungere un ambito al nome, taocpp-json ad esempio json per renderlo univoco. Verificare che non siano presenti conflitti in un motore di ricerca e in altre raccolte di pacchetti.

Raccolte di pacchetti per verificare la presenza di conflitti:

• Topologia
• Pacchetti Debian

Versione

Versione della libreria.

Questo campo è una stringa alfanumerica che può contenere .anche , _o -. Non viene effettuato alcun tentativo di ordinamento delle versioni; tutte le versioni vengono considerate come stringhe di bit e vengono valutate solo per verificarne l'uguaglianza.

Per le porte con tag di rilascio, si segue la convenzione seguente:

1. Se la porta segue uno schema come va.b.c, si rimuove l'elemento iniziale v. In questo caso, diventa a.b.c.
2. Se la porta include il proprio nome nella versione, ad esempio curl-7_65_1, si rimuove il nome iniziale: 7_65_1

Per le porte di rilascio in sequenza, viene usata la data in cui è stato eseguito l'accesso al commit, formattato come YYYY-MM-DD. Ha dichiarato un altro modo: se qualcuno avesse una macchina temporale e andasse a tale data, visualizzerà il commit come il master più recente.

Si consideri ad esempio di avere una situazione simile alla seguente:

1. L'ultimo commit è stato eseguito il 2019-04-19
2. La stringa di versione corrente è 2019-02-14-1
3. La data odierna è 2019-06-01.

Quindi, se si aggiorna la versione di origine oggi, è necessario assegnargli la versione 2019-06-01.

Port-Version

Versione della porta.

Questo campo è un numero intero non negativo. Consente di eseguire la versione del file di porta separatamente dalla versione della libreria sottostante; se si apporta una modifica a una porta, senza modificare la versione sottostante della libreria, è necessario incrementare questo campo di uno (a partire da 0, che equivale a nessun Port-Version campo). Quando la versione della libreria sottostante viene aggiornata, questo campo deve essere impostato di nuovo 0 su (ad esempio, eliminare il Port-Version campo).

Esempi

Version: 1.0.5
Port-Version: 2

Version: 2019-03-21

Descrizione

Descrizione della libreria.

Per convenzione, la prima riga della descrizione è un riepilogo della libreria. Di seguito è riportata una descrizione dettagliata facoltativa. La descrizione dettagliata può essere di più righe, tutte a partire da spazi vuoti.

Esempi

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.

Home page

URL della home page della libreria in cui un utente è in grado di trovare documentazione aggiuntiva o il codice sorgente originale.

Esempio:

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

Build-Depends

L'elenco delimitato da virgole delle porte vcpkg da cui dipende la libreria.

vcpkg non distingue tra dipendenze di sola compilazione e dipendenze di runtime. È necessario specificare l'elenco completo delle dipendenze necessarie per usare correttamente la libreria.

Ad esempio: websocketpp è una libreria di sola intestazione e pertanto non richiede alcuna dipendenza in fase di installazione. Tuttavia, gli utenti downstream necessitano di boost e openssl per usare la libreria. Pertanto, websocketpp elenca boost e apresl come dipendenze.

Se la porta dipende dalle funzionalità facoltative di un'altra libreria, è possibile specificare usando la portname[featurelist] sintassi . Se la porta non richiede alcuna funzionalità dalla dipendenza, deve essere specificata come portname[core].

Le dipendenze possono essere filtrate in base al triplo di destinazione per supportare requisiti diversi. Questi filtri usano la stessa sintassi del campo Supports riportato di seguito e sono racchiusi tra parentesi che seguono il nome porta e l'elenco delle funzionalità.

Esempio

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

Funzionalità predefinite

Elenco delimitato da virgole delle funzionalità delle porte facoltative da installare per impostazione predefinita.

Questo campo è facoltativo.

Esempio

Default-Features: dynamodb, s3, kinesis

Supporti

Espressione che restituisce true quando si prevede che la porta venga compilata correttamente per un triplet.

Attualmente, questo campo viene usato solo nel test CI per ignorare le porte. In futuro, questo meccanismo è destinato a avvisare gli utenti in anticipo che un determinato albero di installazione non dovrebbe avere esito positivo. Pertanto, questo campo deve essere utilizzato ottimisticamente; nei casi in cui si prevede che una porta abbia esito positivo del 10% del tempo, deve comunque essere contrassegnata come "supportata".

Per l'elenco degli identificatori supportati, vedere Platform Expressions (Espressioni di piattaforma) nella documentazione del vcpkg.json manifesto.

Esempio

Supports: !(uwp|arm)

Paragrafi delle funzionalità

Nei file è possibile specificare CONTROL più funzionalità facoltative. Deve avere un campo Feature e Description . Facoltativamente, può avere un Build-Depends campo. Deve essere separato da altri paragrafi da una o più righe vuote.

Esempio

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

Campi riconosciuti

Funzionalità

Nome della funzionalità.

Descrizione

Descrizione della funzionalità che usa la stessa sintassi del campo della porta Description .

Build-Depends

Elenco delle dipendenze necessarie per compilare e usare questa funzionalità.

Durante l'installazione, le dipendenze da tutte le funzionalità selezionate vengono combinate per produrre l'elenco completo delle dipendenze per la compilazione. Questo campo segue la stessa sintassi del Build-Depends paragrafo di origine.