Ler em inglês

Compartilhar via


Perguntas frequentes

O que são o modo clássico e o modo de 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 manifestos para seus projetos no modo clássico na maioria dos casos, pois você tem melhor controle sobre suas dependências. Consulte nosso artigo sobre o modo Manifesto para obter 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.

Como alternativa, se sua meta for preservar binários produzidos por vcpkg install operações para reutilização posterior, consulte o recurso de cache binário

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 vcpkg no modo clássico (executando comandos para gerenciar pacotes, sem arquivo de manifesto), consulte a documentação do vcpkg update 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 Criação de registros. 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}, portanto, para obter binários pré-construídos, você pode escrever um arquivo de porta 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 trigêmeos 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 revise nossa documentação de trigêmeos 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 de manifesto 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 do pacote e de quais bibliotecas de registros 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 X-dev pacotes em vcpkg correspondem aos pacotes or 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, isso é 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 check-in do conjunto específico de arquivos de porta necessários no controle do código-fonte junto com os códigos-fonte do projeto e usar a --vcpkg-root opção de 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 do nosso scripts\buildsystems\vcpkg.cmake no final do arquivo de cadeia de ferramentas existente.

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

Sim. Na versão atual, ainda não existe uma maneira global padronizada de alterá-los, no entanto, você pode editar arquivos de porta individuais e ajustar o processo de compilação exato como desejar.

Ao salvar as alterações no arquivo de porte (e fazer check-in), você obterá os mesmos resultados mesmo se estiver reconstruindo do zero no futuro e esquecer quais configurações exatas usou.

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 no arquivo de $(VcpkgConfiguration) 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 muito mais altas em seu vcxproj para que ele seja declarado antes que a integração do vcpkg seja carregada. É recomendável que a $(VcpkgConfiguration) macro 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 em todo o usuário. Posso usar uma integração por projeto?

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

Um mecanismo de nível inferior para obter o mesmo que o vcpkg integrate project pacote NuGet é por meio do <vcpkg_root>\scripts\buildsystems\msbuild\vcpkg.targets arquivo. 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++/Geral/Diretórios de Inclusão Adicionais" e "Diretórios de Biblioteca Vinculadora/Geral/Adicional" normalmente ficam em branco sem integração em 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.

  • Sabores 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.

  • Por dll vs por aplicativo. 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 dividir as mais altas. 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 controle de versão independente.

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 são todos quebrados de maneiras diferentes. Acreditamos que é uma perda de tempo do usuário escolher a lista de 20+ pacotes públicos para o Boost 1.56 para determinar o punhado que funcionará 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.

  • Por dll vs por aplicativo. 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 controlar o controle de versão de todas as bibliotecas juntas como uma plataforma (semelhante a um gerenciador de pacotes do sistema), esperamos reunir 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 projeta completamente a capacidade de uma biblioteca solicitar versões que entrem em conflito com as escolhas do aplicativo (eu quero openssl Z e boost X, mas X só afirma funcionar com openssl Y).

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

  • 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, ele não foi projetado atualmente 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!).