Perguntas frequentes

O que são os modos clássico e manifesto?

Existem duas maneiras de gerenciar suas dependências com o vcpkg:

1. O modo de manifesto permite que você declare suas dependências diretas, restrições de versão e registros usados em um arquivo chamado vcpkg.json. Esse arquivo deve ser incluído no repositório de código e pode ser verificado no sistema de controle do código-fonte. As dependências são instaladas em uma subpasta chamada vcpkg_installed. Dessa forma, cada projeto de código pode ter seu próprio conjunto de dependências; nada é instalado em todo o sistema. Você pode executar o vcpkg no modo de manifesto executando vcpkg install (sem outros argumentos) ou aproveitando a integração automática com projetos MSBuild e CMake. Recomendamos usar manifests para seus projetos em vez do modo clássico na maioria dos casos, pois você tem melhor controle sobre suas dependências. Consulte nosso Artigo sobre o modo manifesto para mais detalhes.
2. O modo clássico é a maneira mais tradicional de gerenciar dependências, que envolve a execução de comandos vcpkg que especificam cada dependência direta a ser instalada, modificada ou removida. As dependências são armazenadas no diretório de instalação do vcpkg, portanto, vários projetos de consumo podem fazer referência ao mesmo conjunto de dependências. Consulte nosso artigo sobre o modo Clássico para obter mais detalhes.

Posso contribuir com uma nova biblioteca?

Sim! Comece lendo nossas diretrizes de contribuição. Também dê uma olhada em nosso Guia do Mantenedor, que entra em mais detalhes. Também temos um tutorial para adicionar um port ao vcpkg para ajudá-lo a começar.

Se você deseja contribuir, mas não tem uma biblioteca específica em mente, dê uma olhada na lista de novas solicitações de porta.

O vcpkg pode criar pacotes binários pré-construídos? Qual é o formato binário usado pelo vcpkg?

Sim! Consulte o export comando se desejar produzir binários para exportar para outros ambientes.

Se seu objetivo é manter arquivos binários produzidos por essas operações para reutilização posterior, consulte o vcpkg install como alternativa.

Como faço para atualizar bibliotecas?

Se você estiver usando um manifesto (vcpkg.json arquivo) para gerenciar suas dependências, será necessário atualizar esse arquivo. Consulte a documentação de referência de controle de versão para obter detalhes.

Se você estiver usando o vcpkg no modo clássico (executando comandos para gerenciar pacotes, sem arquivo de manifesto), consulte a documentação vcpkg update de comando. Este comando lista todos os pacotes que estão fora de sincronia com seus arquivos de porta atuais. Em seguida, você precisará executar o vcpkg upgrade comando para confirmar as alterações.

Como faço para obter mais bibliotecas?

A lista de bibliotecas é enumerada a partir do ports\ diretório. Por design, você pode adicionar e remover bibliotecas desse diretório como achar adequado para você ou sua empresa – veja nossos exemplos sobre empacotamento de arquivos zip e repositórios do GitHub.

Recomendamos clonar diretamente do GitHub e usar git pull para atualizar a lista de arquivos de porta.

Posso construir uma biblioteca particular com esta ferramenta?

Sim. Siga nosso exemplo de empacotamento para criar sua própria porta e consulte a documentação de portas de sobreposição e registros, para saber como gerenciar suas portas privadas.

Você pode levar isso adiante publicando suas bibliotecas particulares em um registro. Consulte o artigo sobre Registros personalizados. Um registro é uma coleção de portas, semelhante àquela fornecida com vcpkg que contém bibliotecas de código aberto.

Posso usar uma biblioteca particular pré-construída com esta ferramenta?

Sim. O portfile.cmake para uma biblioteca é fundamentalmente um script que coloca os cabeçalhos e binários no arranjo correto no ${CURRENT_PACKAGES_DIR}; assim, para puxar binários pré-construídos, você pode escrever um portfile que baixa e organiza diretamente os arquivos.

Para ver um exemplo disso, veja ports\opengl\portfile.cmake o que simplesmente copia arquivos do SDK do Windows.

Quais plataformas posso segmentar com vcpkg?

Nossos tripletos integrados e testados de integração contínua são:

• Área de trabalho do Windows (x86, x64, x64-static, arm64)
• Plataforma Universal do Windows (x64 e arm64)
• Mac OS X (x64-estático)
• Linux (x64-estático)
• Android (x64, arm64, arm-neon)

Esses alvos são testados com mais rigor quanto à compatibilidade com cada versão do vcpkg. No entanto, temos um número muito maior de trigêmeos da comunidade disponíveis com mais plataformas e arquiteturas, incluindo iOS, MinGW, WebAssembly, freeBSD e openBSD.

Você também pode definir seus próprios trigêmeos dependendo de suas necessidades. vcpkg é muito personalizável.

Consulte vcpkg help triplet a lista atual e consulte nossa documentação de tripletos, para obter mais detalhes.

O vcpkg é executado no Linux / OS X?

Sim! Testamos continuamente no OS X e no Ubuntu 22.04, no entanto, sabemos que os usuários tiveram sucesso com o Arch, Fedora e FreeBSD. Se você tiver problemas com sua distribuição Linux favorita, informe-nos sobre um problema e ficaremos felizes em ajudar!

Como faço para atualizar o vcpkg?

Execute git pull para obter as fontes mais recentes e, em seguida, execute bootstrap-vcpkg.bat (Windows) ou ./bootstrap-vcpkg.sh (Unix) para atualizar o vcpkg. Ou, se você estiver usando uma cópia do vcpkg que é fornecida com o Visual Studio, basta atualizar sua versão do Visual Studio do Instalador do Visual Studio.

Como faço para usar diferentes versões de uma biblioteca em uma máquina?

Sugerimos o uso de arquivos manifest para gerenciar dependências de projetos individuais, o que funciona mesmo se vários projetos estiverem na mesma máquina e permite que você gerencie facilmente as versões de pacotes e de quais registros as bibliotecas estão vindo.

No entanto, se você estiver usando o modo clássico, dentro de uma única instância do vcpkg (por exemplo, um conjunto de installed\, packages\, ports\ e assim por diante), você só poderá ter uma versão de uma biblioteca instalada (caso contrário, os cabeçalhos entrariam em conflito entre si!). Para aqueles com experiência com gerenciadores de pacotes em todo o sistema, os pacotes em vcpkg correspondem aos pacotes X-dev ou X-devel. Nesse caso, para usar diferentes versões de uma biblioteca para diferentes projetos, recomendamos fazer instâncias separadas de vcpkg e usar os mecanismos de integração por projeto. As versões de cada biblioteca são especificadas pelos arquivos no ports\, portanto, são facilmente manipuladas usando comandos padrão git . Isso torna muito fácil reverter todo o conjunto de bibliotecas para um conjunto consistente de versões mais antigas, que funcionam entre si. Se você precisar fixar uma biblioteca específica, é tão fácil quanto verificar a versão apropriada do ports\<package>\. Se o seu aplicativo for muito sensível às versões das bibliotecas, recomendamos fazer o check-in do conjunto específico de portfiles de que você precisa no controle de origem junto com os códigos-fonte do projeto e usar a opção --vcpkg-root para redirecionar o diretório de trabalho do vcpkg.exe.

Como o vcpkg protege minha privacidade?

Consulte o documento Privacidade para obter todas as informações sobre privacidade.

Posso usar meu próprio arquivo de cadeia de ferramentas do CMake com o arquivo de cadeia de ferramentas do vcpkg?

Sim. Se você já tiver um arquivo de cadeia de ferramentas do CMake, precisará incluir nosso arquivo de cadeia de ferramentas no final do seu. Isto deve ser tão simples como uma include(<vcpkg_root>\scripts\buildsystems\vcpkg.cmake) directiva. Como alternativa, você pode copiar o conteúdo de nosso scripts\buildsystems\vcpkg.cmake no final de seu arquivo de cadeia de ferramentas existente.

Posso usar meus próprios sinalizadores/específicos para reconstruir as bibliotecas?

Sim. Você pode usar tripletos personalizados para modificar sinalizadores de compilação por meio das variáveis VCPKG_C_FLAGS e VCPKG_CXX_FLAGS.

Você também pode personalizar os sinalizadores para cada porta individualmente. Por exemplo:

if (PORT MATCHES "my-port")
  set(VCPKG_CXX_FLAGS "-D_CRT_SECURE_NO_WARNINGS")
  set(VCPKG_C_FLAGS "-D_CRT_SECURE_NO_WARNINGS")
endif()

Posso obter integração vcpkg para configurações personalizadas?

Sim. Embora o vcpkg produza apenas as configurações padrão de "Versão" e "Depuração" ao criar uma biblioteca, você pode obter suporte de integração para as configurações personalizadas de seus projetos, além das configurações padrão do seu projeto.

Em primeiro lugar, o vcpkg assumirá automaticamente qualquer configuração personalizada começando com "Release" (ou seja, "Debug") como uma configuração compatível com a configuração padrão "Release" (ou seja, "Debug") e agirá de acordo.

Para outras configurações, você só precisa substituir a macro do MSBuild $(VcpkgConfiguration) no arquivo de projeto (.vcxproj) para declarar a compatibilidade entre sua configuração e a configuração padrão de destino. Infelizmente, devido à natureza sequencial do MSBuild, você precisará adicionar essas configurações em um nível muito mais alto no vcxproj para que ele seja declarado antes que a integração do vcpkg seja carregada. É recomendável que a macro $(VcpkgConfiguration) seja adicionada ao PropertyGroup "Globals".

Por exemplo, você pode adicionar suporte para sua configuração "MyRelease" adicionando seu arquivo de projeto:

<PropertyGroup Label="Globals">
  ...
  <VcpkgConfiguration Condition="'$(Configuration)' == 'MyRelease'">Release</VcpkgConfiguration>
</PropertyGroup>

Obviamente, isso só produzirá binários viáveis se sua configuração personalizada for compatível com a configuração de destino (por exemplo, ambos devem ser vinculados à mesma biblioteca de tempo de execução).

Não consigo usar a integração de todo o usuário. Posso usar uma integração por projeto?

Sim. Um pacote NuGet adequado para uso por projeto pode ser gerado pelo comando vcpkg integrate project (vinculação leve) ou pelo comando vcpkg export --nuget (empacotamento completo).

Um mecanismo de nível inferior para alcançar o mesmo que o pacote NuGet vcpkg integrate project é através do arquivo <vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets. Tudo o que você precisa é importá-lo em seu arquivo .vcxproj, substituindo <vcpkg_root> pelo caminho onde você instalou o vcpkg:

<Import Project="<vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets" />

Como posso remover arquivos temporários?

Se você se preocupa apenas com os pacotes instalados, é seguro excluir os seguintes diretórios dentro da pasta raiz vcpkg:

• packages,
• buildtrees,
• e downloads

Você pode usar o --clean-after-build sinalizador em seu vcpkg install comando para fazer com que o vcpkg exclua os arquivos temporários automaticamente após a conclusão da compilação.

O vcpkg também usa outros locais temporários externos à pasta raiz do vcpkg. Os arquivos de integração do Visual Studio, o cache binário padrão e o cache de registros; estão todos localizados no seguinte caminho, dependendo do seu sistema operacional:

No Windows:

• %LocalAppData%/vcpkg

No Linux/macOS:

• $XDG_CACHE_HOME/vcpkg
• ~/.cache/vcpkg (somente se XDG_CACHE_HOME não estiver definido)

Se você configurou caches binários ou de ativos locais, talvez queira limpá-los periodicamente também, conforme necessário.

Como o CMake é usado internamente pelo vcpkg?

vcpkg usa o CMake internamente como uma linguagem de script de compilação. Isso ocorre porque o CMake já é um sistema de compilação extremamente comum para bibliotecas de código aberto multiplataforma e está se tornando muito popular para projetos C++ em geral. É fácil de adquirir no Windows, não requer instalação em todo o sistema e é legível para usuários desconhecidos.

O vcpkg suporta o download de binários compilados de um servidor público ou privado?

Recomendamos criar suas bibliotecas uma vez com suas configurações de compilação preferidas e usar o recurso de cache binário para reutilizar binários sem precisar recompilar todas as vezes. Isso é útil ao trabalhar em um projeto de equipe ou quando você está criando localmente e em um ambiente de integração contínua em várias máquinas, contêineres, máquinas virtuais etc.

Quais conjuntos de ferramentas MSVC são suportados?

Damos suporte ao Visual Studio 2015 Atualização 3 e superior.

Por que o Visual Studio não usa minhas bibliotecas com a integração em todo o usuário habilitada?

Habilitar a integração em todo o usuário (vcpkg integrate install) altera o padrão para algumas propriedades do projeto. Em particular, “C/C++/General/Additional Include Directories” e “Linker/General/Additional Library Directories” normalmente estão em branco sem integração de todo o usuário. Com a integração, um valor em branco, significa que o padrão aumentado fornecido pelo vcpkg é substituído e os cabeçalhos/bibliotecas não serão encontrados. Para restabelecer o padrão, defina as propriedades para herdar do pai.

Por que não o NuGet?

O NuGet é um gerenciador de pacotes para bibliotecas .NET com uma forte dependência do MSBuild. Ele não atende às necessidades específicas dos clientes nativos do C++ de pelo menos três maneiras.

• Versões de compilação. Com tantas combinações possíveis de opções de compilação, a tarefa de fornecer um conjunto verdadeiramente completo de opções é intrinsecamente impossível. Além disso, o tamanho do download para pacotes binários razoavelmente completos torna-se enorme. Isso torna necessário dividir os resultados em vários pacotes, mas a pesquisa se torna muito difícil.

• Binário vs. Fonte. Intimamente ligado ao primeiro ponto, o NuGet foi projetado desde o início para fornecer binários pré-criados relativamente pequenos. Devido à natureza do código nativo, os desenvolvedores precisam ter acesso ao código-fonte para garantir a compatibilidade, o desempenho, a integridade e a capacidade de depuração da ABI.

• Per-dll vs. Per-application. O NuGet é altamente centrado no projeto. Isso funciona bem em linguagens gerenciadas com ABIs naturalmente estáveis, porque as bibliotecas base podem continuar a evoluir sem quebrar as camadas superiores. No entanto, em idiomas nativos onde a ABI é muito mais frágil, a única estratégia robusta é construir explicitamente cada biblioteca em relação às dependências exatas que serão incluídas no aplicativo final. Isso é difícil de garantir no NuGet e leva a um ecossistema altamente desconectado e com versões independentes.

Por que não Conan?

Conan.io é um gerenciador de pacotes C++ publicamente federado, centrado em projetos e multiplataforma escrito em python. Nossas principais diferenças são:

• Federação pública vs federação privada. Conan depende de indivíduos que publicam cópias independentes de cada pacote. Acreditamos que essa abordagem incentiva um grande número de pacotes que estão todos quebrados de maneiras diferentes. Acreditamos que é uma perda de tempo do usuário analisar a lista de mais de 20 pacotes públicos para o Boost 1.56 para identificar os poucos que realmente funcionarão para sua situação específica. Em contraste, acreditamos que deve haver uma única versão mantida de forma colaborativa que funcione para a grande maioria dos casos e permita que os usuários hackeiem livremente suas versões privadas. Acreditamos que isso resultará em um conjunto de pacotes de alta qualidade que são fortemente testados entre si e formam uma base fantástica para quaisquer modificações privadas que você precisar.

• Per-dll vs. Per-application. Quando as dependências são versionadas de forma independente em um nível de biblioteca, isso incentiva cada ambiente de compilação a ser completamente único, incapaz de tirar proveito ou contribuir para um ecossistema sólido e bem testado. Por outro lado, ao versionar todas as bibliotecas juntas como uma plataforma (semelhante a um gerenciador de pacotes do sistema), esperamos concentrar testes e esforços em conjuntos muito comuns de versões de bibliotecas para maximizar a qualidade e a estabilidade do ecossistema. Isso também elimina completamente a possibilidade de uma biblioteca solicitar versões que podem entrar em conflito com as configurações do aplicativo (eu quero openssl Z e boost X, mas X só reivindica funcionar com openssl Y).

• Multiplataforma vs plataforma única. Embora o fato de estar hospedado em várias plataformas seja uma excelente estrela-guia, acreditamos que o nível de integração e estabilidade do sistema fornecido pelo apt-get, yum e homebrew vale muito a pena trocar apt-get install libboost-all-dev com brew install boost em scripts automatizados. Optamos por tornar nosso sistema o mais fácil possível de integrar em um mundo que já conta com gerentes de sistema altamente bem-sucedidos – acrescentando mais uma linha para vcpkg install boost – em vez de tentar substituí-los onde já são tão bem-sucedidos e queridos.

• C++/CMake vs python. Embora o Python seja uma excelente linguagem amada por muitos, acreditamos que a transparência e a familiaridade são os fatores mais importantes ao escolher uma ferramenta tão importante para o seu fluxo de trabalho quanto um gerenciador de pacotes. Consequentemente, optamos por fazer com que as linguagens de implementação fossem o mais universalmente aceitas possível: C++ deve ser usado em um gerenciador de pacotes C++ para programadores C++. Você não deve ser obrigado a aprender outra linguagem de programação apenas para entender seu gerenciador de pacotes.

Por que não Chocolatey?

Chocolatey é um excelente sistema para gerenciar aplicativos. No entanto, atualmente ele não foi projetado para adquirir ativos de desenvolvedor redistribuíveis e ajudá-lo na depuração. O vcpkg, em comparação, foi projetado para fornecer as bibliotecas necessárias para criar seu aplicativo e ajudá-lo a entregar por meio de qualquer plataforma que desejar (incluindo Chocolatey!).