Conceito: características
Os recursos representam conjuntos de funcionalidade, comportamento e dependências que podem ser adicionados seletivamente a um pacote ou projeto após a instalação.
Por design, os recursos devem seguir estes princípios:
- Aditivo: a habilitação de um recurso deve fornecer uma nova funcionalidade ausente do pacote sem desabilitar qualquer outra funcionalidade.
- Não exclusivo: a habilitação de um recurso não deve impedir que outros recursos sejam instalados.
Os recursos não devem ser usados para definir conjuntos alternativos de funcionalidades. Por exemplo, uma biblioteca de gráficos não deve usar recursos para escolher entre back-ends gráficos exclusivos, já que não é possível instalar todos eles ao mesmo tempo.
Os recursos podem ter os seguintes efeitos nas dependências de um pacote:
- Adicione novas dependências, incluindo dependências em outros recursos do mesmo pacote.
- Habilite novos recursos em dependências existentes.
O conjunto de recursos disponíveis são definidos pelo "features"
campo.
Uma biblioteca de manipulação de imagens, por exemplo, pode oferecer suporte a vários tipos de imagem diferentes, dependendo de diferentes conjuntos de outras bibliotecas.
{
"name": "my-image-lib",
"version": "0.1",
"features": {
"png": { "description": "Support PNG files", "dependencies": ["libpng"]},
"jpeg": { "description": "Support JPEG files", "dependencies": ["libjpeg-turbo"]},
"tiff": { "description": "Support TIFF files", "dependencies": ["libtiff"]},
}
}
Os recursos padrão são um conjunto de recursos a serem ativados automaticamente se o projeto de nível superior não solicitar explicitamente uma compilação sem eles. Os recursos padrão destinam-se a garantir um nível mínimo de funcionalidade, independentemente de quão complexo e personalizável o gráfico de dependência de um projeto cresce.
Observação
Os recursos padrão não se destinam a modelar "curadoria" ou "sugestões".
Por exemplo, considere uma biblioteca "extract-any"
que suporta mais de 10 formatos de arquivo diferentes, incluindo vários que são bastante obscuros. Como todos eles são opcionais, se nenhum for selecionado, a biblioteca não estará funcional: ela não poderá extrair nenhum arquivo.
Os recursos padrão garantem que um usuário que simplesmente adiciona "extract-any"
à lista de dependências em seu vcpkg.json
obterá um nível de linha de base de funcionalidade, por exemplo, selecionando .zip
e .tar.gz
descompactando automaticamente.
Quando um usuário adiciona "extract-any"
recursos sem especificar, os recursos padrão (por exemplo, suporte e .zip
.tar.gz
formatos) são incluídos automaticamente, garantindo a vcpkg.json
funcionalidade básica.
{
"name": "my-application",
"version": "0.15.2",
"dependencies": [
"extract-any"
]
}
Se o usuário quiser desabilitar explicitamente os recursos padrão, ele poderá fazer isso adicionando "default-features": false
à dependência:
{
"name": "my-application",
"version": "0.15.2",
"dependencies": [
{
"name": "extract-any",
"default-features": false
}
]
}
Como alternativa, se estiver usando vcpkg no modo clássico, você pode desativar os recursos padrão por meio do core
recurso. Por exemplo, vcpkg install extract-any[core]
instala extract-any
sem nenhum recurso padrão, pois [core]
os exclui explicitamente.
Para obter mais informações, confira o artigo de recursos padrão.
Ao usar vcpkg, a resolução de dependências desempenha um papel crucial, especialmente ao lidar com recursos que têm interdependências. Para ilustrar, considere o seguinte cenário envolvendo uma biblioteca de manipulação de imagens:
{
"name": "my-image-lib",
"version": "0.1",
"features": {
"png": { "description": "Support PNG files", "dependencies": ["libpng"]},
"jpeg": { "description": "Support JPEG files", "dependencies": ["libjpeg-turbo"]},
"tiff": { "description": "Support TIFF files", "dependencies": ["libtiff"]},
}
}
Em cenários em que bibliotecas diferentes dependem de vários recursos de uma biblioteca comum, o vcpkg garante que todos os recursos e dependências necessários sejam considerados. Por exemplo, se library-a
requer o png
recurso e library-b
requer o jpeg
recurso do , o gráfico de my-image-lib
dependência ficaria assim:
{
"name": "library-a",
"version": "1",
"dependencies": [{"name": "my-image-lib", "features": ["png"]}]
}
{
"name": "library-b",
"version": "1",
"dependencies": [{"name": "my-image-lib", "features": ["jpeg"]}]
}
{
"name": "project-using-a-and-b",
"version": "1",
"dependencies": [
"library-a",
"library-b"
]
}
Quando essas dependências são resolvidas, o vcpkg combina todos os recursos e dependências necessários para formar um plano de instalação abrangente. Neste exemplo, um projeto depende de ambos library-a
e resultaria em um plano de instalação que inclui ambos PNG
e JPEG
suporte de my-image-lib
, mas não TIFF
library-b
:
libjpeg-turbo[core]
libpng[core]
library-a[core]
library-b[core]
my-image-lib[core,png,jpeg]
Esse mecanismo garante que a compilação de my-image-lib
seja otimizada para os recursos necessários, fornecendo suporte para PNG
e JPEG
excluindo suporte desnecessário TIFF
.
Quando um único repositório contém vários componentes compiláveis separados, como aplicativos cliente e servidor com algum código compartilhado, os desenvolvedores de cada parte podem querer evitar a instalação de dependências caras exigidas por outras partes.
{
"name": "my-game",
"dependencies": ["grpc"],
"features": {
"client": { "description": "Client Game Executable", "dependencies": ["sdl2", "bullet3"]},
"server": { "description": "Multiplayer Server Executable", "dependencies": ["proxygen"]},
"tests": { "description": "Build tests", "dependencies": ["gtest"] }
}
}
Os desenvolvedores individuais podem selecionar quais recursos instalar:
- Na linha de comando de instalação, passe
--x-feature=
- Ao usar o CMake Integration, defina
VCPKG_MANIFEST_FEATURES
antes doproject()
comando. - Ao usar a integração do MSBuild, passe
--x-feature=
porVcpkgAdditionalInstallOptions
Para saber mais, consulte o seguinte:
Comentários do vcpkg
O vcpkg é um projeto código aberto. Selecione um link para fornecer comentários: