Partilhar via

Arquivos CONTROL

  • Artigo

Aviso

CONTROL Os arquivos são preteridos e mantidos apenas para compatibilidade com versões anteriores do VCPKG. Use vcpkg.json arquivos de manifesto para qualquer porta recém-criada.

Use ./vcpkg format-manifest path/to/CONTROL para converter um arquivo existente CONTROL em um vcpkg.json arquivo.

O CONTROL arquivo contém metadados sobre a porta. A sintaxe é baseada no formato Debiancontrol, embora só suportemos o subconjunto de campos documentados aqui.

Os nomes de campo diferenciam maiúsculas de minúsculas e iniciam a linha sem espaço em branco à esquerda. Os parágrafos são separados por uma ou mais linhas vazias.

Parágrafo de origem

O primeiro parágrafo em um CONTROL arquivo é o parágrafo Origem. Deve ter um Source, Versione Description campo. O conjunto completo de campos está documentado abaixo.

Exemplos

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

Campos reconhecidos

Origem

O nome da porta.

Ao adicionar novas portas, esteja ciente de que o nome pode entrar em conflito com outros projetos que não fazem parte do vcpkg. Por exemplo json , entra em conflito com muitos outros projetos, então você deve adicionar um escopo ao nome, de modo taocpp-json a torná-lo exclusivo. Verifique se não há conflitos em um mecanismo de pesquisa, bem como em outras coleções de pacotes.

Coleções de pacotes para verificar conflitos:

Versão

A versão da biblioteca.

Esse campo é uma cadeia de caracteres alfanumérica que também pode conter ., _ou -. Nenhuma tentativa de ordenar versões é feita; Todas as versões são tratadas como cadeias de bits e são avaliadas apenas quanto à igualdade.

Para portas de liberação marcada, seguimos a seguinte convenção:

  1. Se a porta seguir um esquema como va.b.c, removemos o à esquerda v. Neste caso, torna-se a.b.c.
  2. Se a porta incluir seu próprio nome na versão como curl-7_65_1, removemos o nome principal: 7_65_1

Para portas de lançamento contínuo, usamos a data em que a confirmação foi acessada por você, formatada como YYYY-MM-DD. Dito de outra forma: se alguém tivesse uma máquina do tempo e fosse até essa data, veria esse compromisso como o último mestre.

Por exemplo, considerando que:

  1. O último compromisso foi feito em 2019-04-19
  2. A cadeia de caracteres da versão atual é 2019-02-14-1
  3. A data de hoje é 2019-06-01.

Então, se você atualizar a versão de origem hoje, você deve dar-lhe versão 2019-06-01.

Versão da porta

A versão da porta.

Este campo é um inteiro não negativo. Ele permite que se faça a versão do arquivo de porta separadamente da versão da biblioteca subjacente; Se você fizer uma alteração em uma porta, sem alterar a versão subjacente da biblioteca, deverá incrementar esse campo em um (começando em 0, que é equivalente a nenhum Port-Version campo). Quando a versão da biblioteca subjacente é atualizada, esse campo deve ser definido novamente como 0 (ou seja, excluir o Port-Version campo).

Exemplos
Version: 1.0.5
Port-Version: 2

Version: 2019-03-21

Descrição

Uma descrição da biblioteca.

Por convenção, a primeira linha da descrição é um resumo da biblioteca. Segue-se uma descrição detalhada opcional. A descrição detalhada pode ser de várias linhas, todas começando com espaço em branco.

Exemplos
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

A URL da página inicial da biblioteca onde um usuário pode encontrar documentação adicional ou o código-fonte original.

Exemplo:

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

Build-Depende

Lista separada por vírgulas de portas vcpkg das quais a biblioteca tem uma dependência.

vcpkg não distingue entre dependências somente compilação e dependências de tempo de execução. A lista completa de dependências necessárias para usar a biblioteca com êxito deve ser especificada.

Por exemplo: websocketpp é uma biblioteca somente de cabeçalho e, portanto, não requer dependências no momento da instalação. No entanto, os usuários downstream precisam de boost e openssl para fazer uso da biblioteca. Portanto, websocketpp lista boost e openssl como dependências.

Se a porta depender de recursos opcionais de outra biblioteca, eles poderão ser especificados usando a portname[featurelist] sintaxe. Se a porta não exigir nenhum recurso da dependência, isso deverá ser especificado como portname[core].

As dependências podem ser filtradas com base no triplete de destino para oferecer suporte a requisitos diferentes. Esses filtros usam a mesma sintaxe do campo Suportes abaixo e são colocados entre parênteses após o nome da porta e a lista de recursos.

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

Recursos padrão

Lista separada por vírgulas de recursos de porta opcionais a serem instalados por padrão.

Esse campo é opcional.

Exemplo
Default-Features: dynamodb, s3, kinesis

Suporta

Expressão que é avaliada como true quando se espera que a porta seja compilada com êxito para um triplete.

Atualmente, esse campo é usado apenas no teste de CI para ignorar portas. No futuro, este mecanismo destina-se a avisar os usuários com antecedência de que uma determinada árvore de instalação não deve ter sucesso. Portanto, este campo deve ser usado de forma otimista; Nos casos em que se espera que uma porta seja bem-sucedida em 10% das vezes, ela ainda deve ser marcada como "suportada".

Consulte Expressões de plataforma na documentação do manifesto vcpkg.json para obter a lista de identificadores com suporte.

Exemplo
Supports: !(uwp|arm)

Parágrafos em destaque

Vários recursos opcionais podem ser especificados nos CONTROL arquivos. Deve ter um Feature e Description campo. Opcionalmente, pode ter um Build-Depends campo. Ele deve ser separado dos outros parágrafos por uma ou mais linhas vazias.

Exemplo

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

Campos reconhecidos

Recurso

O nome do recurso.

Descrição

Uma descrição do recurso usando a mesma sintaxe do campo de porta Description .

Build-Depende

A lista de dependências necessárias para criar e usar esse recurso.

Na instalação, as dependências de todos os recursos selecionados são combinadas para produzir a lista completa de dependências para a compilação. Este campo segue a mesma sintaxe do Build-Depends Parágrafo de Origem.